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(57) ABSTRACT 

A storage controller has at least one physical data port for a 
data network including host processors. The storage con- 
troller is programmed to provide a plurality of virtual ports 
for access to storage, and a virtual switch for routing storage 
"access requests from the physical port to the virtual ports. 
The virtual ports and the virtual switch are defined by 
software. The virtual ports appear to the hosts as physical 
ports in the data network. For example, in a Fiber-Channel 
network, the virtual ports have World Wide Names (WWNs) 
and are assigned temporary addresses (S_Ds), and the 
virtual switch provides a name server identifying the WWNs 
and S_„IDs of the virtual ports. For convenient partitioning 
of storage among host processors, one or more virtual ports 
are assigned to each host, and a set of storage volumes are 
made accessible from each virtual port. A host can access 
storage at a virtual port only if the virtual port has been 
assigned to the host. Preferably, storage can be accessed 
through each virtual port by no more than one assigned host, 
although a shared volume may be accessible from more than 
one virtual port. The storage controller may provide a 
service for reporting to a host the virtual ports ±rough which 
the host can access storage, and the storage volumes that are 
accessible to the host through each of the virtual ports. 

15 Claims, 28 Drawing Sheets 
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VIRTUAL PORTS FOR DATA 
TRANSFERRING OF A DATA STORAGE 
SYSTEM 

BACKGROUND OF THE INVENTION 5 

1. Technical Field 

The present invention relates generally to data processing 
networks and data storage subsystems, and more particularly 
to a data processing network in which a large number of 
hosts can access volumes of data storage in a data storage 
subsystem. 

2. Description of the Related Art 

Due to advances in computer technology, there has been 
an ever increasing need for data storage in data processing 
networks. In a typical data processing network, there has 
been an increase in the number of volumes of data storage 
and an increase in the number of hosts needing access to the 
volumes. This has been especially true for networks of 
workstations. Not only have a greater number of worksta- ^ 
tions been added to the typical network, but also the increase 
in data processing capabilities of a typical workstation has 
required more data storage per workstation for enhanced 
graphics and video applications. 

The increased demand for data storage in a network is 25 
typically met by using more storage servers in the network 
or by using storage servers of increased storage capacity and 
data transmission bandwidth. From the standpoint of cost of 
storage, either of these solutions appears to be satisfactory. 
However, a greater number of storage servers in a network 3Q 
substantially increases the cost of managing the storage. 
This increased cost of management often appears some time 
after installation, when one of the servers reaches its capac- 
ity and some of its volumes must be reassigned to less 
heavily loaded servers. Network administrators aware of the 35 
cost of storage management realize that networit storage 
should^be consoUdated to the minimum possible number of 
servers: The management problem is reduced by reducing 
the number of objects to be managed. 

Due to the storage needs of present networks and the 40 
desire to consoHdate servers, it is practical to provide a 
single storage subsystem with up to 20 terabytes (TB) 
storage, or approximately 4000 logical volumes. It may be 
possible for any host to have access to any volume in a data 
storage subsystem to which the host has access. However, it 45 
may be *^desirable to restrict the set of volumes that can be 
seen by any one host. Restricted access is desirable for 
security of private data. For example, private volumes 
should be assigned to each host for storage of private data, 
and other hosts should not be permitted to see or modify the 50 
private volumes of other hosts. Moreoycr> the "boot" process 
for a host is slowed down by searching for and reporting all 
thHTolumes to which the host has access. Certain operating 
systems are limited by the number of storage devices that 
they can manage at a given period of time, and for a host ss 
running such an operating system, it is not only desirable but 
also necessary to limit the number of volumes that the host 
can access. 

It is possible to restrict access of a host to a limited set of 
logical volumes in the data storage subsystem by restricting 60 
the set of logical volumes accessible through a particular 
port adapter of the storage subsystem and linking the host to 
only that particular port adapter. For convenience, however, 
there should not be any restrictions on which logical storage 
volumes are accessible from each port adapter. Otherwise, 65 
during a reconfiguration of the data processing system, it 
may be necessary to physically switch the hnks that are 
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connected to the network ports of the hosts or the port 
adapters, for example by manually disconnecting and recon- 
necting the links to the ports. Even in the case where the data 
network has a fabric for automatically establishing a link 
between any of the hosts and any of the port adapters, the 
physical possibility of any port adapter to access any logical 
storage volume provides alternative data paths that could be 
used in case of port adapter failure or port adapter conges- 
tion. For example, if a host sends a data access request to a 
port adapter and receives a busy response from the port 
adapter, then the host can send the data access request to 
another port adapter. Port adapter congestion is likely, for 
example, if the storage subsystem is a continuous media 
server, in which video data is often streamed through a 
single port adapter to a host for a relatively long period of 
time. 

In open network systems, it is known to use authentication 
and authorization protocols in order to authenticate that a 
request for access to a specified file originates from a 
particular host, and once the request for access is 
authenticated, to check whether the host is authorized to 
access the specified file. For example, a network server 
authenticates the request by checking whether a password in 
the request matches the hosts' password stored in a client 
directory, and the network server authorizes the request by 
checking a file directory to determine whether the host is 
listed in the file directory as having access rights to the 
specified file. However, the use of high-level authentication 
and authorization procedures for discriminating among all 
access requests by the hosts to the logical storage volumes 
would unduly burden the host and the storage subsystem. 
What is desired is a method that may be transparent to any 
high-level file system procedures that may be used by the 
hosts for managing access to files stored in the logical 
voliunes to which a host is permitted to access. The method 
should restrict the logical storage volumes seen by the host 
during a boot operation, and seen by the operating system 
when the operating system determines what logical volumes 
are accessible to the host. 

SUMMARY OF THE INVENTION 

In accordance with one aspect of the invention, there is 
provided a data storage subsystem that includes data storage 
and a storage controller coupled to the data storage for 
controlling access to the data storage. The storage controller 
has at least one physical data port for connecting the storage 
controller into a data network for data transmission between 
the data storage and host processors in the data network. The 
storage controller is programmed to provide a plurality of 
virtual ports that are not physical ports in the data network 
but that appear to the host processors to be physical ports in 
the data network that provide access to the data storage and 
that are connected to the physical data port by a switch in the 
storage controller for routing storage access requests from 
the physical data port to the virtual ports. 

In accordance with another aspect, the invention provides 
a data storage subsystem including data storage and a 
storage controller coupled to the data storage for controlling 
access to the data storage. The storage controller has at least 
one physical data port for connecting the storage controller 
into a data network for data transmission between the data 
storage and host processors in the data network. The storage 
controller is programmed to provide a plurality of virtual 
ports that are not physical ports in the data network but that 
appear to the host processors to be physical ports in the data 
network that provide access to the data storage and that are 
connected to the physical data port by a switch in the storage 
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controller for routing storage access requests from the 
physical data port to the virtual ports. The storage controller 
is programmed with a permanent network name for each of 
the virtual ports, and with a temporary network address for 
each of the virtual ports. The storage controller is pro- 5 
grammed to route from the physical data port to a specified 
virtual port a storage access request containing a temporary 
address that specifies the specified virtual port. The storage 
controller is also programmed to provide access at each 
virtual port to only a respective assigned subset of the data 
storage. The storage controller is prograromed to permit 
assignment of more than one virtual port to each host 
processor such that each host processor may access storage 
from every virtual port assigned to the host processor. The 
storage controller is further progranuned so that none of the 
virtual ports is assigned to more than one host processor so 
that not more than one host processor may access the data 
storage from any one of the virtual ports. 

In accordance with another aspect, the invention provides 
a machine -readable program storage device containing a 20 
program that is executable by a storage controller for 
controlling access to data storage. The storage controller has 
at least one physical data port for connecting the storage 
controller into a data network for data transmission between 
the data storage and host processors in the data network. The 25 
program is executable by the storage controller to provide a 
plurality of virtual ports that are not physical ports in. the 
data network but that appear to the host processors to be 
physical ports in the data network that provide access to the 
data storage and that are connected to the physical data port 30 
by a switch in the storage controller for routing storage 
access requests from the physical data port to the virtual 
ports. 

In accordance with yet another aspect, the invention 
provides a machine-readable program storage device that is 35 
executable by a storage controller for controlling access to 
data storage. The storage controller has at least one physical 
data port for connecting the storage controller into a data 
network for data transmission between the data storage and 
host processors in the data network. The program is execut- 40 
able by the storage controller to provide a plurality of virtual 
ports that are not physical ports in the data network but that 
appear to the host processors to be physical ports in the data 
network that provide access to the data storage and that are 
connected to the physical data port by a switch in the storage 45 
controller for routing storage access requests from the 
physical data port to the virtual ports. The program is 
executable by the storage controller so that the storage 
controller will have a permanent network name for each of 
the virtual ports and a temporary network address for each 50 
of the virtual ports. The program is executable by the storage 
controller to route from the physical data port to a specified 
virtual port a storage access request containing a temporary 
address that specifies the specified virtual port. The program 
is executable by the storage controller to provide access at 55 
each virtual port to only a respective assigned subset of the 
data storage. The program is executable by the storage 
controller to permit assignment of more than one virtual port 
to each host processor such that each host processor may 
access storage from every virtual port assigned to the host go 
processor. The program is also executable by the storage 
controller so that none of the virtual ports is assigned to 
more than one host processor so that not more than one host 
processor may access the data storage from any one of the 
virtual ports. 6S 

In accordance with still another aspect, the invention 
provides a method of operating a storage controller for 
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controlling access to data storage. The storage controller has 
at least one physical data port for connecting the storage 
controller into a data network for data transmission between 
the data storage and host processors in the data network. The 
method includes the storage controller receiving storage 
access requests from the host processors at the physical data 
port, inspecting network addresses in the storage access 
requests to find network addresses of virtual ports in the 
storage controller to which the storage access requests are 
directed, and controlling access to the data storage in accor- 
dance with the network addresses of the virtual ports to 
which the storage access requests are directed. The virtual 
ports are not physical data ports in the data network, but the 
storage controller is operated to cause the virtual ports to 
appear to the host processors to be physical ports in the data 
network that provide access to the data storage and that are 
connected to the physical data port by a switch in the storage 
controller for routing storage access requests from the 
physical data port to the virtual ports. 

In accordance with a final aspect, the invention provides 
a method of operating a storage controller for controlling 
access to data storage. The storage controller has at least one 
physical data port for connecting the storage controller into 
a data network for data transmission between the data 
storage and host processors in the data network. The method 
includes the storage controller receiving storage access 
requests from the host processors at the physical data port, 
and inspecting network addresses in the storage access 
requests to find network addresses of virtual ports in the 
storage controller to which the storage access requests are 
directed, and controlling access to the data storage in accor- 
dance with the network addresses of the virtual ports to 
which the storage access requests are directed. The virtual 
ports are not physical data ports in the data network, but the 
storage controller is operated to cause the virtual ports to 
appear to the host processors to be physical ports in the data 
network that provide access to the data storage and that are 
connected to the physical data port by a switch in the storage 
controller for routing storage access requests from the 
physical data port to the virtual ports. The storage controller 
maintains a permanent network name for each of the virtual 
ports and a temporary network address for each of the virtual 
ports. The storage controller provides access at each virtual 
port to only a respective assigned subset of the data storage. 
The storage controller permits assignment of more than one 
virtual port to each host processor such that each host 
processor may access storage from every virtual port 
assigned to the host processor. Moreover, none of the virtual 
ports is assigned to more than one host processor so that not 
more than one host processor may access the data storage 
from any one of the virtual ports. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Other objects and advantages of the invention wiU 
become apparent upon reading the following detailed 
description with reference to the accompanying drawings 
wherein: 

FIG. 1 is a block diagram of a data processing system 
including a cached storage subsystem linked by a data 
network to a multiplicity of host processors; 

FIG. 2 is a block diagram of the data processing system 
of FIG. 1 further showing a typical fault-tolerant implemen- 
tation for the data network; 

FIG. 3 is a generalized block diagram of a node linked to 
the data network of FIG. 1; 

FIG. 4 is a block diagram of the data processing system 
of FIG. 1 showing a port adapter in the cached storage 
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subsystem using a volume access table for assignment of 
logical storage volumes to respective host controller ports; 

FIG. 5 is a diagram showing a simplified construction that 
could be used for the volume access table introduced in FIG, 
4; 

HG. 6 is a diagram of a volume list entry defining a vector 
of logical storage volumes in a disk spread; 

FIG. 7 is a block diagram of the cached storage subsystem 
showing further data structures used with the volume access 
table stored in port adapter memory; 

FIG. 8 is a diagram showing a preferred construction for 
a volume access table stored in the cache memory as 
introduced in FIG. 7; 

FIG, 9 is a diagram showing a preferred construction for 
the volume access table stored in port adapter memory; 

FIG. 10 is a diagram of a directory for searching the 
volume table of FIG. 9; 

FIG. 11 is a flowchart of a microcode routine executed by 
a port adapter of the cached storage subsystem of FIG. 1 
when using the volume access table of FIG. 5 or FIG. 9 in 
response to a "Report LUNs" or access request by a host 
processor; 

FIG, 12 is a flowchart of a microcode routine executed by 
a port adapter of the cached storage subsystem of FIG. 1 
when converting the vector representation of FIG. 6 to a list 
of logical storage volume numbers; 

FIG. 13 is a flowchart of a microcode routine executed by 
a port adapter of the cached storage subsystem of FIG. 1 
when determining whether a specified logical storage vol- 
ume is included in a disk spread defined by the vector 
representation of FIG. 6; 

FIG, 14 is a graphical display of disk spreads in a 
two-dimensional volume space; 

FIG. 15 is a graphical display of disk spreads in a 
three-dimensional volume space; 

FIG. 16 is a flowchart of a microcode routine executed by 
a port adapter of the cached storage subsystem of FIG. 1 for 
volume configuration when installing the storage subsystem 
into the data processing system of FIG. 1; 

FIG. 17 is a flowchart of a microcode routine executed by 
a port adapter of the cached storage subsystem of FIG. 1 
when notified of a network state change such as a host 
controller boot; 

FIG. 18 is a flowchart of a procedure performed by a 
system administrator during host controller replacement; 

FIG. 19 is a diagram of a volimie list that comprises a 
mapping table for mapping logical unit numbers (LUNs) to 
logical storage volume numbers; 

FIG. 20 is a diagram of a volume list that comprises a 
mapping table for mapping ranges of LUNs to vectors of 
logical storage volimie numbers; 

FIG. 21 is a schematic diagram of the data processing 
system of FIG. 1 showing one of the port adapters pro- 
grammed to provide virtual ports for access to respective 
groups of logical storage volumes; 

FIG. 22 is a schematic diagram of a data processing 
system in which port adapters are programmed to permit a 
host to access the same virtual ports through the physical 
ports of more than one of the port adapters. 

FIG. 23 is block diagram of data structures of volume 
access and mapping information stored in memory of port 
adapters of the storage subsystem of FIG. 21 or FIG. 22; 

FIG. 24 is a diagram of a virtual port host table included 
in the volume access and mapping information of FIG. 23; 
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FIG. 25 is a diagram of a virtual port mapping table 
included in the volume access and mapping information of 
FIG. 23; 

FIG. 26 is a flow chart of a routine performed by a port 
5 adapter when reporting the virtual ports accessible to a host 
controller port; 

FIG. 27 is a first sheet of a flow chart of a routine 
performed by a port adapter when responding to a volume 
access request or "Report LUNs" request from a host; 

FIG. 28 is a second sheet of the flow chart begun in FIG. 
27; 

FIG. 29 is a diagram of a display generated by a graphical 
user interface to show a mapping relationship between 
15 logical volumes, storage adapter ports, and LUNs at a virtual 
port; 

FIG. 30 is a diagram of a display generated by a graphical 
user interface to establish a mapping between volumes 
accessible at a virtual port for a host and the LUNs at the 
20 virtual port; 

FIG. 31 is a block diagram of a semiconductor integrated 
circuit chip capable of authenticating itself in a secure 
fashion; 

FIG. 32 is a block diagram showing semiconductor inte- 
^ grated circuit chips in accordance with FIG. 31 being used 
in the data processing system of FIG, 1 to permit a port 
adapter to authenticate the identity of host controllers; 

FIG. 33 is a flowchart of a "challenge-response*' proce- 
diu-e used by the port adapter and host controllers of FIG. 32 
to permit the port adapter to authenticate the identity of a 
host controller; 

FIG. 34 is a block diagram showing components of a 
Fibre Channel Frame; 
35 FIG. 35 is a first sheet of a flowchart of a procedure used 
by the port adapter and host controllers of FIG. 32 to permit 
the port adapter to authenticate each message from a host 
controller; 

FIG. 36 is a second sheet of the flowchart begun in FIG. 
40 35; 

FIG. 37 is a block diagram of a storage network configu- 
ration especially suited for up to 800 workstations; 

FIG. 38 is a block diagram of a storage network configu- 
ration especially suited for up to 3300 workstations; 

FIG. 39 is a block diagram of a storage area network 
providing fault tolerance and failover capability for hosts 
and storage subsystems in the network; and 

FIG. 40 is a block diagram of a storage area network 
50 similar to that shown in FIG. 39 but including additional 
network loops for higher throughput. 

While the invention is susceptible to various modifica- 
tions and alternative forms, specific embodiments thereof 
have been shown in the drawings and will be described in 
55 detail. It should be understood, however, that it is not 
intended to limit the invention to the particular forms shown, 
but on the contrary, the intention is to cover all 
modifications, equivalents, and alternatives falling within 
the scope of the invention as defined by the appended 
60 claims. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

With reference to FIG. 1 of the drawings, there is shown 
65 a cached storage subsystem 20 connected via a data network 
21 to a plurality of hosts 22, 23, 24, 25. The cached storage 
subsystem 20 includes storage volumes 26 and a storage 
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controller 27 for controlling access of the hosts to the storage 
volumes. The storage volumes are logical units of storage 
distributed over one more storage devices 28, 29, 30, and 31. 
The storage devices are magnetic disk drives, optical disk 
drives, tape drives, solid-state memory devices, or other 
storage devices capable of providing nonvolatile data stor- 
age. Presently the preferred storage devices are magnetic 
disk drives each having a storage capacity of at least 46 
gigabytes. 

The storage controller 27 includes a dual port cache 
memory 32, a pluraUty of port adapters 35, 36, and a 
plurality of storage adapters 37, 38. The cache memory 32 
is accessed via any one of two back-plane busses 33, 34. 
Each of the port adapters 35, 36 Unk the data network 21 to 
each of the two back-plane busses 33, 34. Each of the 
storage adapters 37, 38 links a respective set of the storage 
devices 28, 29, 30, 31 to each of the two back-plane busses 
33, 34. For example, the cached storage subsystem includes 
up to eight storage adapters and up to eight port adapters, 
and each port adapter provides two independent data ports to 
the data network. 

When a port adapter 35 or 36 receives a storage access 
request from one of the hosts 22, 23, 24, 25, the port adapter 
accesses a directory in the cache memory 32 to determine 
whether or not the data to be accessed resides in the cache 
memory. If the data to be accessed resides in the cache 
memory, then the port adapter accesses the data in the cache 
memory. If the data to be accessed does not reside in the 
cache memory, then the port adapter forwards a storage 
access request to the storage adapters 37, 38. One of the 
storage adapters 37, 38 responds to the storage access 
request by performing a logical-to-physical translation to 
determine where the data to be accessed resides on the 
storage devices, and reads the data from the storage devices 
and writes the data to the cache memory, for access by the 
port adapter. The storage adapters 37, 38 also perform a 
write-back operation to ensure that that data written to the 
cache memory 32 by the port adapters eventually becomes 
written to the storage volumes 26. 

The cache memory 32 ensures that data frequently 
accessed by the hosts is likely to be found in cache in order 
to avoid the data access time of the storage devices and in 
order to minimize loading on the storage adapters and the 
port adapters. Consolidation of network storage into a large 
cached storage subsystem provides a benefit that cache 
resources are consohdated into one large cache, which is 
more efficient than a number of smaller caches having in 
total the same cache memory capacity. A large cache is more 
likely to contain the most recently accessed data than the 
combined cache memory of the smaller caches. 

The storage subsystem 20 is constructed for high data 
availability so that a single high-capacity storage subsystem 
is at least as fault- tolerant as a local collection of conven- 
tional network storage servers. Fault tolerance is ensured by 
dual, redundant components and busses in the path from any 
one of the port adapters 35, 36 to any one of the storage 
devices 28, 29, 30, and 31. Mirroring or RAID (redundant 
array of inexpensive disks) techniques ensure that the stor- 
age adapters 37, 38 can recover data in the event of failure 
of any one of the storage devices. In a similar fashion, the 
data network 21 can be made fault tolerant by ensuring that 
each of the hosts 22, 23, 24, 25 has independent paths 
through the data network 21 to each of two of the port 
adapters 35, 36, as will be further described below with 
reference to FIG. 2. 

In a preferred form of construction, the cache memory 32 
is composed of dynamic RAM memory cards mounted in a 
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card-cage or main-frame, and the port adapters and storage 
adapters are programmed micro-processor cards that are also 
mounted in the card-cage or main-frame. Each port adapter 
35, 36 has one or more processors for handUng the com- 

5 mimication protocol of the data network 21 and communi- 
cating with the cache memory busses 33, 34. Each storage 
adapter 37, 38 has one or more processors for handhng the 
communication protocol of the storage devices and for 
communicating with the cache memory busses 33, 34. For 
example, the links between the storage adapters 37 and the 
storage devices 28, 29, 30, and 31 are FWD (fast, wide, 
differential) SCSI or Fibre Chaimcl fiber-optic loops. The 
port adapters 35, 36 can be programmed to communicate 
with the network via any number of communication and/or 

j5 network protocols, such as Bus and Tag CKD, ESCON, 
SCSI, Ethernet, FDDI, ATM, DSl, DS3, T3, TCP, UDP, 
NTFS, SNMP, and Fibre Channel. Further details regarding 
the preferred construction and operation of the cached 
storage subsystem 20 are disclosed in Yanai et al., U.S. Pat. 

20 No, 5,206,939, issued Apr. 27, 1993; Yanai et aL U,S. Pat, 
No. 5,335,352, issued Aug. 2, 1994; and Yanai et al. U.S. 
Pat. No. 5,381,539, issued Jan. 10, 1995; all incorporated 
herein by reference. 
Referring to FIG. 2, there is shown a fault-tolerant way of 

25 connectiDg a large number of hosts 22, 23, 24, 25 to the 
cached storage subsystem 20. In this example, the data 
network 21 includes a respective loop 41, 42, 43, 44 
connected to each port of the port adapters 35, 36, and each 
host has at least two ports, each of which is connected to a 

30 respective loop connected to the port of a different one of the 
port adapters. Therefore, if there is a single failure of any one 
of the loops or a single failure of any one of the port 
adapters, there wDl still be an operational path from each 
host to the internal back-plane busses (33, 34 in FIG, 1) in 

35 the cached disk storage subsystem. The loops 41, 42, 43, 44, 
for example, operate in accordance with the Ethernet or 
Fibre Channel standards. Each loop coxild connect up to fifty 
hosts, for a total of 400 hosts connected via dual-redundant 
paths from eight port adapters. For workstation hosts where 

40 dual-redundant paths would not be needed, only one port of 
each workstation could be connected to the network 21, so 
that up to 800 workstations could be connected to the storage 
subsystem by cormecting this single port of each workstation 
to only one of sixteen loops, as will be further described 

45 below with reference to FIG. 37. 

It is possible to replace each of the loops 41-44 in FIG. 
2 with a switch, or to use switches together with loops for 
connectiDg hosts to the storage subsystem, as will be further 
described below with reference to FIG. 38. In general, for a 

50 given number of ports, a loop will be less expensive that a 
switch, but a switch may provide more bandwidth that a 
loop. The additional bandwidth of a switch may be needed 
for ensuring concurrent host access to the storage subsystem 
or for supporting bandwidth-intensive applications such as 

55 interactive video applications. 

In general, the data network 21 of FIG, 1 could have 
various topologies and simultaneously use a number of 
different communication protocols. For example, the data 
network 31 could connect ports of various devices by 

60 dedicated port-to-port connections (i.e., so-caUed point-to- 
point connections), loops, or switches, or combinations of 
these connections. In addition to switches, the data network 
21 could include other connectivity devices such as hubs, 
bridges and routers. The data network 31 could include 

65 additional processors or computers for buffering or stream- 
ing data from the cached storage subsystem to hosts or to 
archival storage such as a tape Ubrary. For example, the use 
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of a cached storage subsystem in connection with stream Iq a Fiber Channel network, the portion of the network 

servers, a tape library, and an ATM switch, for continuous- connected to each port has one of four distinct topologies; 

media isochronous data access, and on-line backup storage, namely, point-to-point, private loop, public loop, and fabric, 

is described in Vishlitzky et al., U.S. Pat, No. 5,737,747 A point-to -point topology has one port connected directly to 

issued Apr. 7, 1998. 5 one other port. A loop is a single simplex media linking three 

The data network 21 could also include one or more or more nodes such that transmission can occur between a 

additional cached storage subsystems, preferably at different single pair of nodes on the media at any given time. A hub 

geographical locations, to provide redundancy and pro tec- is a specific implementation of a loop in which a node can 

tion from a catastrophic failure of the cached storage sub- be inserted into or removed from the hub without breaking 

system 20, as will be further described below with reference jq the loop. A private loop is a dedicated or closed loop. A 

to FIGS. 39 and 40. The cached storage subsystems could be pubUc loop is a loop attached to a node of a fabric. A fabric 

linked for automatic remote mirroring of data to provide is a topology that permits multiple simultaneous transmis- 

recovery from a disaster, as described in Yanai et al., U.S. sions between pairs of nodes connected to it. The fabric 

Pat. No. 5,544,347 issued Aug. 6, 1996, incorporated herein routes or switches data frames from a source node to a 

by reference, and in Yanai et al., U.S. Pat. No. 5,742,792 destination node. A switch is an implementation of the fabric 

issued Apr. 21, 1998 (Ser. No. 08/654,511 filed May 28, topology. 

1996), incorporated herein by reference. In a Fiber Channel network, a node of a host directly 

Because the data network 21 could have various connected to a loop can determine all other nodes in the loop 

topologies, it is desirable to provide a facility for enabling by polling. A response from a node on the loop can indicate 

any device in the network to determine the configuration of 20 whether or not the responding node is or is not a fabric port, 

at least that portion of the network that is accessible to the When a node is identified, its associated LUNs can be 

device. With reference to FIG. 3, for example, there is shown requested by sending a Report LUNs request to the node. A 

a ^Se*55*i^^g a number of ports, including ports 51 and node of a fabric port can be further interrogated about the 

52, which may be connected to the data network 21. In this identity of other nodes of the fabric to which the node of the 

context, the node SlTcan. represent any device having ports 25 fabric port is directly coimected through the fabric. For 

which may be connected to the data network 21. The node example, associated with the fabric is a "name server" that 

also has a number of entities 53, 54, 55, 56, which are will respond with a list of nodes directly accessible through 

accessible through one or more of the ports, and which are the fabric. The name server has a predefined address on the 

identified by logical unit numbers (LUNs), each of which is fabric. A node of the host can also probe the configuration 

unique for any single node. For example, if the node 50 is 30 of a point-to-point connection or loop connected to each 

a storage.subsystem, each logical storage volume is assigned node directly accessible through the fabric, by addressing a 

a unique LLFN! As will be further described below, it is also port of the fabric to route interrogation requests to other 

possible to establish a mapping between the LUNs as ports. 

specified by or reported to a host and the logical volumes, so A request from one port to another on a loop or fabric 

that one logical volume could be mapped to more than one 35 must identify the destination port so that only the destination 

LUN. Each port^Sl, 52 is constructed or programmed to port wiU respond to the request. A request from one port to 

respond to a "Report LUNs" command by retiu-ning a list of another on a loop or fabric must also identify the source of 

LUNs which are accessible from the port. In the fashion, a the request so that a response can be directed back to the 

host can send "Report LUNs" commands to each port of source. Although the WWNs of the source and destination 

each storage subsystem to which it is connected, to obtain a 40 ports could be used in each request to uniquely identify the 

list offtthc logical volumes to which the host is connected. source and destination ports, each WWN contains so many 

THis"is typically done by a host operating system at "boot" bits that an undue amount of transmission bandwidth and 

time. data processing capability would be expended if the source 

The format for the Report LUNs command and the and destination WWNs were used in each request, 
manner of its use by the host is determined by the protocol 45 Therefore, it is desirable to assign a temporary identifier to 
used by the network. For example, for a host connected to each port in the data network in such a fashion that the 
a storage node via a SCSI link, then the host addresses the identifier is unique to the configuration of the network at any 
storage volume by a Bus/Target/LUN triple,, and the host given time, but not necessarily unique to each port for all 
can send a SCSI "Report LUNs" command over the bus to time. Therefore, such a temporary identifier can have fewer 
each target on the bus to obtain a list of LUNs accessible 50 bits than a WWN yet uniquely identify a source or desired 
through each target. Such a Report LUNs command is destination of a request transmitted through the network, 
subsumed in the Fibre Channel standards, which define The Fiber Channel standards specify that data is trans- 
additional capabilities for permitting a host to determine the mitted over the Fiber Channel network in packets having a 
present configuration of a network to which the host is predefined format, and such a packet is called a "frame." 
connected. The Fibre Channel standards are currently being 55 Each frame includes a sotircc address (S_ID) and a desti- 
developed by the American National Standards Institute nation address (D_JD). The S_ID is a temporary identifier 
(ANSI). of the port which is the source of the frame, and the D_ID 

In a Fibre Channel network, each port has a 64-bit port is a temporary identifier of the port which is the desired 

identifier called a "World Wide Name" (WWN), To ensure destination of the frame. Further details regarding the fonmat 

that the WWN is unique, for example, it may include a 60 of the frame are described below with reference to FIG. 34. 

unique identifier of the manufacturer of the device including The use of temporary rather than permanent identifiers for 

the port (e.g., an Organizationally Unique Identifier as source and destination addresses in the network introduces 

registered with the IEEE in New York, N.Y), and the the problem of assigning and reassigning the temporary 

manufacturer's serial number of the device. A logical storage identifiers when the configuration of the network is defined 

volume in a Fibre Channel storage subsystem therefore can 65 and changed. For example, when a private loop is changed 

be identified by the combination of the WWN of the storage into a public loop by coimecting a port of a switch to the 

subsystem and the LUN of the logical volume. loop, temporary addresses must be assigned to other ports of 
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the switch and to the ports of devices that become connected logical storage volume, it may be desirable to restrict the set 

to those other ports. of volumes that can be seen by any o^ host. Certain 

If a Fiber Chamiel network includes a fabric, then the "p^^^olumes should be assigned to eactfiiost and other 

temporary identifiers of ports in the network are assigned by hosts^should not be permitted to see or modify the private 
the fabric at the time of a fabric login if the fabric supports 5 volumes of other hosts. Moreover, the "boot'* process for a 

a fabric login. Otherwise, the temporary identifiers must be host is slowed down by searching for and reporting all the 

known by the ports implicitly. For example, in a fabric volumes to which the host has access. Certain operating 

containing only one switch, when that one switch is powered systems are Umited by the number of devices that they can 

on or reset, then that one switch implicitly knows its own handle at a given period of time, and for a host using such 
ports, and a "domain controller" of the switch searches for lO an operating system, it is not only desirable but also neces- 

nodes connected to the switch ports, assigns temporary IDs sary to limit the number of volumes that the host can acxess. 

to all the nodes that become known to it, and reports to the The problem of restricting the set of volumes that can be 

ports that it has found the temporary IDs assigned to them. seen by any one host is solved by a method of named groups 

During this fabric login process, a "name server*' of the and/or a method of virtual ports. The method of named 
fabrictmay-build a table of the WWNs of the ports that are 15 groups is applicable to all Fiber Channel topologies for the 

knownitp the fabric and their corresponding temporary IDs. connections of hosts to one or more ports of a storage 

If the Fibre Channel network includes multiple switches, controller. The method of virtual ports causes at least one 

then only one of them, designated as the master switch, port of the storage controller to appear as if it were a port of 

assigns ranges of temporary IDs to be used by each of the a fabric. The method of virtual ports could cause the port of 
switches during the fabric login process. The Fibre Channel 20 the storage controller to appear as if it were a Fibre- Channel 

network can be constructed so that the name server auto- FL__Port (a port in a loop that is part of a fabric), E_Port (a 

matically obtains information from the domain controller port that is an interlink between two switches), or F_Port 

when the domain conu-oller learns about the ports that (fabric port). The two methods could be used at the same 

become coimected to the network, or the Fibre Channel time in the same storage controller. In either the method of 
network can be constructed so that a port must log into the 25 named groups or the method of virtual ports, the limited set 

domain controller to obtain its temporary ID, and then log of volumes accessible to a host can be specified by a list of 

into the name server so that the name server obtains the logical volumes in the limited set, or by a procedure that 

temporary ID of the port. The first case is known as an defines the limited set of volumes. An example of a speci- 

implicit name server login, and the second case is known as fication for a procedure that defines the limited set of 

an explicit name server login. volumes is a vector defining what will be called a "disk 

After an initial fabric login process, it is possible for the spread." 

configuration of the network to become changed as a result Referring to FIG. 4, there are shown further details of the 

of addition or replacement of devices having ports con- data processing system of FIG. 1. In FIG. 4, each of the hosts 

nected to the network. The data processing system could be 22, 23, 24 and 25 is shown to have a respective host 

shut down and then reconfigured so that the new ports controller 61, 62, 63, 64 for each host port 65, 66, 67, 68 

become known imphcitly, or a fabric login could be initiated directly linked to the port adapter 35. In the context of this 

so that temporary IDs become assigned to the new ports. In specification, the term "host controller" refers to the con- 

the case of a data network having a fabric supporting a fabric troller of the host ports on the data network. In the data 

login, it is also possible for a device added to the network to processing art, such a host controller is often referred to as 
initiate a process of obtaining temporary IDs for its ports by ^ a "host bus adapter'' or "HBA", The term "host controller" 

requesting a "port login" from the fabric. will be used instead to avoid confusion with the "port 

The Fiber Channel specifications provide a mechanism adapter" of the storage controller or storage subsystem. Each 

for the network to automatically detect certain changes of host controller 61, 62, 63, 64 is programmed with a unique 

state which may indicate that the configuration of the system WWN for circuitry in the host controller for each of the 

has changed. For example, idle signals are transmitted over respective ports 65, 66, 67, 681. In other words, if a host 

the links to enable detection of link failure. Frame trans- controller is replaced with a different host controller, the 

mission errors are detected by cyclic redundancy checks and WWN associated with the host port will change. Moreover, 

sequence identification numbers in the frames. When trans- a host controller may provide more than one port, and the 

mission over a link is restored after detection of a link host controller is programmed with a different WWN for 

failure, a fabric may require the ports connected by the link each of its ports. 

to login for reassignment of temporary IDs to the ports. A As further shown in FIG, 4, the port adapter 35 includes 
fabric may also support a "state change notification" process port circuitry 71 and 72 for each of its two ports 73 and 74. 
in which ports having operational Links to the fabric may The port circuitry, for example, includes application-specific 
request to be notified by the fabric when a state change is integrated circuits (ASICs) for communicating over the 
detected. loops 41 and 43 in accordance with the Fibre Channel 
As described above, the data processing system in FIG. 1 standards. The port circuitry is connected to an input/output 
has facilities for ensuring that the logical storage volumes bus 75 of a microprocessor 76. The microprocessor 76 is 
28, 29, 30, and 31 are accessible to the hosts 22, 23, 24, 25. connected to a random access memory 77 by a memory bus 
It is not only physically possible for any host to have access so microprocessor 76 is also interfaced to the storage 
to any logical volume in the data storage subsystem, but for controllet busses 33 and 34. The memory 77 stores micro- 
fault tolerance is desirable for there to be at least two cod^^executed= by the microprocessor 76. 
independent paths through the data network 21 and through STORAGE VOLUME PARTITIONING BY NAMED 
the cached storage subsystem from each host to each logical GROUPS 

storage volume. 65 in order to restrict the set of volumes that can be seen by 

Although it may be physically possible in the data pro- any one host, the memory 77 of the port adapter 35 stores 

cessing system of FIG. 1 for any host to have access to any information defining a correspondence between hosts in the 
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data processing system and the set of volumes accessible to cally if both the S JDs and WWNs would happen to change, 

each host through the port adapter. For example, a volume for example as a result of host controller replacement and a 

access table 80 and volume lists 81 are stored in the memory change in the configuration of the data network. In this 

77. The volume access table specifies a correspondence situation, the host controller port can transmit its corre- 

between hosts and respective lists of volumes accessible to 5 sponding group name to the storage subsystem during a 

the hosts. A back-up copy of the volume access table and login process or in response to a request from the storage 

volume list could be stored in one of the storage volumes of subsystem in response to a state change notification so that 

the cached storage subsystem, the storage subsystem can reestablish the relationship of the 

The information in the volume access table 80 and the host controller port's volume group name and volume list 

volume Usts 81 can be accessed by a system administrator 10 with respect to its new WWN and S_ID. 

viewing a display 91 and operating a keyboard 92 of a In the table 82 of FIG. 5, for example, the entry 

service processor 93 interfaced to the controller busses 33, "HOST22-1" indicates the first controller port of host no. 22, 

34. The display 91, keyboard 92, and service processor 93, and it could be coded as a number 221, although the entry 

for example, are provided by a conventional lap-top com- could be displayed as "HOST22-1" for viewing by the 

puter mounted behind a door (not shown) in the cabinet (not 15 system administrator. The other entries in the table are 

shown) of the storage controller. The service processor 93, shown as hexadecimal numbers. The volume access table 

for example, is programmed to provide a graphical user itself can have any suitable organization in the port adapter 

interface for volume configuration, partitioning, and other memory 77, such as a fixed-size block of contiguous 

storage management functions. The service processor also memory locations, or doubly-linked Usts of the table entries, 

has a floppy-disc drive for down-loading of the microcode 20 The specification of the particular volumes in a volimie 

79 from a from a floppy-disc program carrier 95. group should permit flexibility in assigning a variable num- 
Altematively, a system administrator at a remote terminal or ber of volumes to each group, and also permit flexibility in 
host could access the information in the volume access table defining overlap between the groups corresponding to cer- 

80 and volume lists 81 and down -load microcode via a tain volumes that are shared by the host processors, 
modem or dedicated link or via the data network (21 in FIG. 25 However, controller memory is a valuable resource, and it is 
1) using an appropriate communications protocol such as the necessary to rapidly determine whether or not a volume 
Simple Network Management Protocol (SNMP). specified by a storage access request fi:om a host controller 

Referring to FIG. 5, there is shown a simplified construe- port is included in the port's volume list. The searching of 

tion for a volume access table 82. A preferred form of a long list of pseudo-random logical volume numbers, for 

construction for the volume access table 80 in FIG. 4 will be 30 example, would directly impact storage access time. Search 

described below with reference to FIGS. 7 to 10. In the time is especially critical in a cached storage system, since 

simplified construction of FIG. 5, each entry in the volume the search time may be comparable to the data access time 

access table includes a volume group name, a host controller if the requested data resides in the cache memory. In any 

port WWN, a host controller port S_1D, a private/shared case, the assignment of a long list of pseudo-random logical 

flag, and a pointer to a volume list. The volume group name 35 volume numbers complicates the storage management 

includes a host name and a number identifying a particular problem, because it is difficult for the storage administrator 

one of possibly many host ports linked to the port adapter. to comprehend how the volumes are assigned or shared 

The volume group name provides a stable and unique when the volimaes in the volume list become nearly full and 

identification number for a group of logical storage volumes additional volimacs must be allocated to the hosts, 

to be accessed firom a host port. At any given time, the S_ID 40 Hashing techniques can be used to search a long volume 

and host controller port WWN also provide unique identi- list rather efficiently, for example, by xising the last couple of 

fication numbers for the volume group, but the S_ID is digits of the specified logical volume number as a hash table 

changed upon booting of the host controller, and the WWN index. Since the list is changed infrequently, the list entries 

is changed upon controller replacement. Using a stable ID can be sorted for a binary search procedure. Moreover, it is 

permits automation of booting, and simplifies management 45 possible to reduce the number of entries in the volume list 

of controller replacement. Moreover, by providing a path and speed up the search process by specifying a range or 

through the data network firom a host controller to each port vector of volume numbers in each list entry. Shown in FIG. 

adapter and by including an entry in the volume access table 6, for example, is a volume list entry 83 specifying a 

in each port adapter defining a volume group name for the beginning volume number 84, an ending volume number 85, 

host controller, it is possible to provide port independence in so and a value 86 of one minus a stride (S). For example, the 

the sense that a host controller may access its corresponding beginning volume number 84 is coded in three bytes, the 

set of logical volumes through any of the port adapters. ending volume number is coded as three bytes, and the stride 

When set, the private/shared flag indicates that all of the is coded as two bytes. The stride (S) indicates the difference 

logical volumes in the volume list are private and no between neighboring volume numbers of the volumes in a 

permission is needed from a lock manager before the host 55 disk spread. The stride (S), for example, is a positive integer 

controUer port can accessing any logical volume in its ranging from 1 to 256 decimal, 

assigned volume list. Refening to FIG. 7, there is shown a preferred form of 

The volume group names and the volumes in each volume constmction in which the volume access table 80 in the 

list are defined by the system administrator. The host con- memory 77 of the port adapter 35 stores only the volume 

troUer port WWNs are entered into the volume access table 60 access information need for processing of a data access 

80 automatically during installation or replacement of a host request by a host controller, and an additional volume access 

controller. The host controller S _1D is entered and updated table 88 in the cache memory 32 stores information that 

automatically dming each boot. The system administrator appears in the table 82 of FIG. 5 but is not needed to process 

defines the host names, for example, by sequentially assign- a data access request by a host controller. The table 80 in the 

ing numbers to the hosts. The host names are also known to 65 port adapter memory 77 is further identified as a "transient" 

the hosts, so that the relationship between each host and the volume access table because it includes the transient S^Ds 

volumes assigned to the host can be re-established automati- of the host controller ports that have logged in to the port 
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adapter 35. The table 88 in the cache memory 32 is further 
identified as a "persistent" volume access table because it 
includes the relatively permanent WWNs of the host con- 
troller ports that have logged in to the port adapter 35. As 
further shown in FIG. 7, the port adapter 36 has a similar 5 
transient volume access table 87 in its port adapter memory 
90. The transient volume access table 87 includes the 
transient S_lDs of the host controller ports that have logged 
in to the port adapter 36. In this case, example, the persistent 
volume access tabic 88 includes the WWNs of the host 
controller ports that have logged in to the port adapter 90 in 
addition to the WWNs of the host controller ports that have 
logged in to the port adapter 35. It is desirable to share a 
persistent volume access table among a number of transient 
volume access tables in the case where a host controller may 
access the same volume group from the ports of different 
port adapters, since this avoids duplication of persistent 
volume access tabic entries that would otherwise occur. Also 
shown in FIG. 7 are volume attributes and locking infor- 
mation 89 stored in the cache memory 32, and respective 20 
table directories 97, 98 that are stored in the port adapter 
memories 77, 90 and used to speed up the process of 
searching the transient volume access tables 80 and 87. 

The persistent volume access table 88 and the volume 
attributes and locking information 89 also reside in a logical 25 
storage volume and be maintained in cache in a fashion 
similar to any other logical storage volume accessed by a 
host controller. However, it is preferred to locate the per- 
sistent volume access table 88 and the volume attributes and 
locking information in a reserved area of cache memory, 30 
called "shared memory/' that is never deallocated, so that 
this informatioD will always be found in the cache memory 
when a port adapter attempts to access it. 

Referring to FIG. 8, there is shown a preferred construc- 
tion for the persistent volume access table 88. The persistent 35 
volume access table 88 includes an entry for each distinct 
group of volumes to be accessible to a particular host 
controller from a particular port adapter. The persistent 
volume access table 88 has columns for volume group 
names, host controller WWNs, a private/shared flag, and 40 
pointers to volume lists, and these columns are similar to the 
corresponding columns in the table 82 of FIG. 5. The 
persistent volume access table 88 further includes columns 
for a volume bitmap and a port adapter index list. A volume 
bitmap has a respective bit for each logical volume in the 45 
storage subsystem, and the respective bit is set if the logical 
volume associated with the bit is included in the volume list, 
and not set if the logical volume associated with the bit is 
excluded from the volume list. The port adapter index list 
includes the table index of each corresponding entry in a 50 
transient volume access table. Therefore, the port adapter 
index list could include an index for each port adapter to 
which the host controller is currently logged into. It may be 
desirable, but not necessary, for the hosts to log out of the 
port adapters. This would ensure that the volume access ss 
tables more precisely reflect the current state of the data 
network, and prevent any misdirection of messages if a 
network failure would prevent a storage adapter from being 
notified of a state change that would cause any S_1D in the 
transient volume access table to be reassigned. eo 

In the persistent table 88 of FIG. 8, the information in 
each volume bitmap is redundant with the information in 
each volume list. In this case, the volume list is the original 
form of the information as specified by the system admin- 
istrator at configuration time. The volume bitmap is used for 65 
rapidly searching whether a specified volume is in the 
volume list, for example in response to a data access request 
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from the host controller port to which the volume list is 
associated. Hie voltmie bitmap is generated automatically 
from the volume list when the volume list is entered or 
modified by the system administrator. The volume list is 
retained for viewing and revision by the system administra- 
tor In a system with a limited number of logical volumes, 
the volume list could be quickly generated firom the volume 
bitmask, and therefore there would be no need to retain the 
volume list it in memory or include the volume list in the 
volume access table. 

Referring to FIG. 9, there is shown a preferred format for 
the transient volume access table 80. The table 80 includes 
an entry for each host controller port currently logged into 
the port adapter. The table 80 includes columns for the host 
controller S_JD, the private/shared flag for the volume list, 
the volume bitmap, and a persistent table index. The per- 
sistent table index in each entry of the transient volume 
access table 80 points to the entry in the persistent volume 
access table having the same private/shared flag and volume 
bitmap as the entry of the transient volume access table, and 
having a host controller WWN corresponding to the host 
controller S_ID in the entry of the transient volume access 
table. 

Referring to FIG. 10, there is shown a preferred format for 
the table directory 93. The table directory includes, in each 

entry, a list of pairs of the S JD and corresponding index to 

the transient volume access table for each SID having a 
certain modulus of the S _JD. The modulus each S _JD in 
the table directory corresponds to the index of the directory 
table entry containing the S_ID. For example, the modulus 
of the S_ID is a certain number of least significant bits of 
the S_ID, and in this case the number of entries in the table 
directory 93 is two raised to the number of the least 
significant bits. 

To search the transient volume access table 80 for an entry 
having a specified host controller S JD, an index is com- 
puted by masking off the least significant bits of the specified 
S_JD to obtain the corresponding modulus, and the modu- 
lus is used to index the table directory to find a list of S__IDs 
and corresponding indices that should include the specified 
S_JD if the specified S_JD is somewhere in the transient 
volume access table. The list in the entry indexed by the 
modulus is searched for the specified SID, and if it is found, 
then its corresponding index is the index to the transient 
volume access table entry containing the specified S _JD. If 
the specified SID is not found in the list in the entry indexed 
by the modulus, the specified S _IT> does not appear in the 
S_ID column of the transient volume access table. 

Since S_IDs are assigned to hosts controller ports 
sequentially when the host controller ports share a loop, the 
size of the table directory 93 can be determined based on 
reasonable constraints on the network geometry. For 
example, if the most complex network geomeu-y connects a 
certain maximum number of loops to one or both of the two 
physical ports of the port adapter (for example, as described 
below with reference to FIG. 38), then the number of entries 
in the table directory can be chosen to be greater or equal to 
the maximum number of host controller ports on a single 
loop, and the number of pairs of S_JDs and corresponding 
transient table indices in each entry of the table directory can 
be set to the maximum number of loops that can be con- 
nected to each port through one switch. However, the 
number of possible S_lDs in each entry of the table direc- 
tory 97 can be reduced stiU further if one assumes a 
particular kind of connection between each loop and each 
port adapter port. For example, if a single switch is used to 
connect loops to the port adapter (for example, as shown in 
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FIG. 38), and all of the host controller ports are assigned 
S_IDs sequentially by this switch, then the number of 
entries in the table directory can be chosen to be the smallest 
power of two greater or equal to the maximum number of 
host controller ports linked to the port adapter ports, and 
there will be at most one S_ID and corresponding transient 
volume access table index in each entry of the table direc- 
tory. 

Referring to FIG. 11, there is shown a flowchart of a 
microcode routine executed by the microprocessor (76 in 
FIG. 4) of the port adapter (35 in FIG. 4) in response to a 
"Report LUNs" or access request by a host. In a first step 
101, the microprocessor decodes the S_ID from the request. 
Then in step 102, the microprocessor searches the volume 
access table for an entry having the S_ID from the request. 
For example, this is done by indexing the table directory of 
FIG. 10 with a modulus of the S_ID from the request, 
searchmg the indexed entry of the table directory for the 
S_ID from the request, and if the S_ID from the request is 
found in the entry, then indexing the volume access table of 
FIG. 9 with the corresponding index in the entry of the table 
directory. If the S _ID of the request is not foimd in the 
volume access table, then execution branches to step 104 to 
report no LUNs or deny the access request, and the routine 
is finished. 

If the S_ID of the request is found in the volume access 
table, then execution continues to step 105. In step 105, the 
volume bitmap or volume list is accessed. For ttie volume 
access table format of FIG. 9 the volume bitmap is accessed, 
and for the volume access table format of FIG. 5, the volume 
hst is accessed. In step 106, execution branches to step 107 
for a "Report LUNs" request. In step 107, the port adapter 
reports to the host controller a storage LUN for each volume 
in the volume bitmap or volume list, and the routine is 
finished. For an access request, execution continues from 
step 106 to step 108. In step 108, execution branches to step 
109 if the volume to access is not in the volume bitmap or 
volume hst. For a bitmap, this can be done simply by 
addressing the bit corresponding to the logical volimie 
specified by the host controller. In general, the volume list is 
searched by using a technique most suitable for quickly 
searching the voltmie list In step 109, the port adapter 
denies the storage controller access to the logical volume, 
and the routine is finished. 

If the volume to access is in the volume bitmap or list, 
then execution continues from step 108 to step 110. In step 

110, the private/shared flag is inspected for the indexed entry 
of the volume access table. If the private/shared flag is set, 
then execution continues from step 110 to step 111. In step 

111, the port adapter accesses the logical volume specified 
by the host controller, and the routine is finished. If the 
private/shared flag is not set, then execution branches from 
step 110 to step 112 to access the locking information the 
cache memory. If the private/shared flag is set, then access 
is permitted, and execution branches from step 113 to step 
111 to access the volume. If the volume to access is public 
and is already locked in a fashion incompatible with the 
access requested by the host (e.g., the volume is already 
write locked and the host controller requests a read or a write 
access, or the volume is already read locked and the host 
controller requests a write access) then access is not pres- 
ently permitted. The host controller's S JD is placed on a 
wait list, in order to notify the host controller when the 
logical volume becomes available; execution branches fi:om 
step 113 to step 114 to temporarily deny access to the 
volume, and the routine is finished. If the volume to access 
is public and is not locked or is locked in a fashion 
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compatible with the requested access by the host controller 
(e.g., the volume is already read locked and the host con- 
troller requests a read access), then a lock is granted to the 
host controller, and execution branches fi-om step 113 to step 

5 111 to access the volume, and the routine is finished. 

Referring to FIG. 12, there is shown a flowchart 120 of a 
microcode routine 120 executed by the microprocessor (76 
in FIG. 4) of the port adapter (35 in FIG. 4) when converting 
the vector representation of FIG. 6 to a list of logical storage 

10 volume identifiers. This routine is used, for example, in step 
106 to report the storage LUNs in a disk spread defined by 
an entry in the volume list. In a first step 121, an index (I) 
is set to the first volume number (BEGIN) for the disk 
spread. Next, in step 122, the value of the index I is inserted 

15 onto the list. Then in step 123, the value of the index is 
compared to the last volume number (END) of the disk 
spread. If the value of the index is greater or equal to the 
value of the last volume number (END), then the routine 
terminates. Otherwise, execution continues from step 123 to 

20 step 124. In step 124, the index (I) is incremented by the 
stride (S), and execution loops back to step 122. 

Referring to FIG. 13, there is shown a flowchart 130 of a 
microcode routine executed by the microprocessor (76 in 
FIG. 4) of the port adapter (35 in FIG. 4) when determining 

^ whether or not a specified logical storage volume is included 
in a disk spread defined by the vector representation of FIG. 
6. This routine is used, for example, in step 107 to determine 
whether or not the volume specified by a data access request 
is included in a disk spread defined by an entry of the volume 
list. In a first step 131, the volume index (I) is compared to 
the first logical volume number (BEGIN) of the disk spread. 

If the volume index (1) is less than the first logical volume 
number, the execution retums indicating that the specified 

2^ logical storage volume is not included in the disk spread. 
Otherwise, execution continues from step 131 to step 132. In 
step 132, the volume index (I) is compared to tiie last logical 
volume ntmiber (END) of the disk spread. If the volume 
index (I) is greater than the last logical volume number, then 

^ execution returns indicating that the specified logical storage 
volume is not included in the disk spread. Otherwise, 
execution continues from step 132 to step 133. 

In step 133, the stride (S) is compared to one. If the stride 
(S) is equal to one, then execution returns indicating that the 

45 specified logical storage volume is not included in the disk 
spread. Otherwise, execution continues to step 134, In step 
134, the difference is calctdated between the index I and the 
first logical volume number (BEGIN) of the disk spread. 
Then a value REM is computed which is the modulus of the 

50 difference (DIF) and the stride (S), In particular, if the 
difference (DIF) is zero, then REM is zero. Otherwise, DIF 
is divided by S using an integer division procedure, and 
REM is the remainder of the division. If REM is zero, then 
execution returns indicating that the specified logical vol- 

55 ume is in the disk spread; otherwise, execution returns 
indicating that the specified logical volume is not in the disk 
spread. 

Refening to FIG. 14, there is shown a graphical display 
140 of disk spreads in a two-dimensional volume space. For 

60 example, the logical volumes 10 to 112 are arranged as a 
four-by-four square matrix. The rows of the matrix corre- 
spond to respective disk spreads defined by the respective 
vectors V0=(O, 3, 1), Vlo(4, 7, 1), V2^8, 11, 1), and 
V3=(12, 15, 1). For each of these row vectors VO to V3, the 

65 stride (S) is one. Also shown is a disk spread defined by a 
column vector V4 «(2, 14, 4) having a stride (S) of foiir. In 
a multi-processor system, for example, the disk spreads 
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representedbyeachof the row vectors VO, VI, V2,V3 could returniag the S _yD and WWN associated with the group 

be assigned to a respective one of four host processors, and name, as tested in step 163, then execution continues to step 

the disk spread represented by the column vector V4 could 164. In step 164 the system administrator enters a volume 

be assigned to a fifth host processor. In this case, none of the list for the group name, for example by entering logical 

first four processors would share any of the volumes with 5 volume numbers, ranges of logical volume numbers, or 

any other of the first four processors, but each of the first vector specifications (beginning number, ending number, 

four processors would share one volume with the fifth stride) at the keyboard 92 in FIG. 4. In step 165, the 

processor. In this fashion, a limited amount of information microprocessor creates a table entry for the group name and 

can be stored in the memory of a port adapter to define a its associated S_JD, WWN, and a pointer to the volume list, 

rather large number of volumes having various shared and 10 ^^^P execution continues to step 167 if the system 

private relationships among a multiplicity of host proces- administrator has no more group names to enter; otherwise, 

sors. execution loop back to step 161. In step 167, the volume 

Referring to FIG. 15, there is shown a graphical display ^^^^^ ^^^^ volume lists are copied to a storage volume 

of disk spreads in a three-dimensional volume space. The ^ back-up for port adapter error recovery or diagnostic 

volume space includes 4,096 volumes, or 16 volumes along 15 Ptoses* and the routine if finished. The back-up copy 

each of the x, y, and z axes. Shown in this volume space is should be updated if additional group names are added to the 

a first disk spread defined by a vector V5-(0, 15, 1) having volume access table or if the volume fists are changed, 

a stride (S) of one, a second disk spread defined by a vector If the polling is not successful in returning a S_JD and 

(15, 255, 16) having a stride (S) of sixteen, and a third disk WWN for a host or group name, then execution branches 

spread defined by a vector V7-(255, 4095, 256). By using 20 ^^^P ^^^P ^^^P ^^^^^ found 

such a three-dimensional graphical display, it is possible to are reported to the system administrator, who has the option 

show complicated private and shared relationships between of creating or not creating a table entry if the items cannot 

the volumes accessible to a large number of host computers. be found. For example, it is possible for the system admin- 

For example, the service processor 93 in FIG. 4 could istrator to permit a table entry to be created for host 

provide such a three-dimensional view on the display. The 25 controllers that are not presently logged into the data 

volumes associated with a particular group name could be network, and the port adapter can fill in the missing items 

displayed in a corresponding primary color, so that the automatically if and when the host controller are booted. If 

private and sharing relationships for up to three selected the system administrator has selected the option of not 

group names or host controller ports could be displayed creating a table when items are missing, then execution 

simultaneously. For example, in FIG. 15, the disk spread 30 branches from step 169 to step 166. Otherwise, execution 

specified by the vector V5 could be associated with a first continues from step 169 to step 170. In step 170, the S_ID 

host processor and displayed in red, the disk spread specified and WWN for the group name is set to null, and then 

by the vector V6 could be associated with a second host execution continues to step 164. 

processor and displayed in blue, and the disk spread speci- Referring to FIG, 17, there is shown a flowchart 180 of a 
fied by the vector V7 could be associated with a third host 35 microcode routine executed by the microprocessor (76 in 
processor and displayed in green. Therefore the shared FIG. 4) of the port adapter (35 in FIG. 4) when notified of 
volume 115 would be displayed in magenta, and the shared a network state change such as a host controller boot. In a 
volume 1255 would be displayed in cyan. Moreover, the first step 181, the port adapter obtains the WWN, the S_[D, 
service processor could be programmed to display a colored and the group name of the host controller port. Then in step 
two-dimensional 16x16 square matrix of the logical vol- 40 182, the volume access table is indexed with the group 
umes for any selected one of 16 planes parallel to the x, y, name. If no entry for the group name is found in the table, 
or z axes in the logical volume space. In addition to then the routine is finished. Otherwise, execution continues 
indicating the private and shared relarionships of the vol- to step 183. In step 183, the WWN obtained from the host 
umes to the hosts, the two-dimensional displays could controller port is compared to the WWN in the table entry, 
provide additional information in the display region of each 45 If the WWN obtained from the host controUer port is the 
volume, such as a numeral or graph indicating of the free same as the WWN in the table entry, then execution con- 
storage space in each volume. tinues from step 183 to step 184. In step 184, the S __D value 
Referring to FIG. 16, there is shown a flowchart 160 of a in the table entry is reset to the value obtained by the port 
microcode routine executed by the microprocessor (76 in adapter in step 181, and the routine is finished. 
FIG. 4) of the port adapter (35 in FIG. 4) for volume so If in step 183 the WWN obtained from the host controller 
configuration when installing the storage subsystem into the port is dififerent from the WWN in the table entry, then 
data processing system of FIG. 1, In a first step 160, the execution branches from step 183 to step 186. In step 186, 
system administrator enters a group name for a host to be execution branches to step 188 if the WWN in the table entry 
permitted access through one or more port adapters. For is null. The nufl value in the table indicates that the system 
example, the system administrator manually operates the 55 administrator has authorized the WWN to be set during a 
keyboard 92 in RG. 4 to enter the host name, host controller controUer boot, for example just after an authorized instal- 
number(s), and port adapter number(s). The service proces- lation or change of a host controller circuit board. Therefore, 
sor 93 forwards this information to the port adapter(s) and in step 188 the WWN and S_JD obtained in step 181 arc 
the microprocessor(s) in the port adapter(s) allocate(s) a entered into the entry of the volume access table, and the 
table entry for each host controller number and places the 60 routine is finished. In step 186, if the WWN entry is not null, 
respective group name into each table entry. Then in step then an unauthorized change in a host controller circuit 
162, the port adapter(s) automatically search the network for board has occurred, and execution branches from step 186 to 
the S_ID and WWN of the host controller ports correspond- step 187 to report the error to the system administrator, and 
ing to the group names. For example, the port adapters poll then the routine is finished. 

the ports of the hosts, and the host controllers are pro- 65 Referring to FIG, 18, there is shown is a flowchart of the 

grammed to respond to port adapters by returning their host procedure that should be performed by a system adminis- 

names and controller numbers. If the polling is successful in trator during host controUer replacement. In step 201 the 
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host is interrupted to suspend any cximmuQication over the 
data network or shut down to permit replacement of the host 
controller. Unless the host controller board has a "hot swap" 
capabihty, the host will be shut down to shut off power to the 
controller board before it is removed and replaced. Then in 
step 202, the system administrator nullifies the host control- 
ler's WWN in all such WWN entries in all volume access 
tables in all port adapters of the storage subsystem, and in 
step 203 the host controller is replaced. The replacement of 
the host controller board causes the WWNs of the ports of 
the host controller board to change. In step 204, host 
processing is restarted or continued, including a boot of the 
new host controller board, and the procedure is finished. 

MAPPING OF LUNs TO LOGICAL VOLUME NUM- 
BERS 

As described above with reference to FIG. 7, a host may 
request access to a specified logical volume in the storage 
subsystem. If a host may access only a very limited set of the 
logical volumes in the data storage subsystem, however, it 
may be desirable for the port adapter to report back to each 
host a limited range of LUNs representing logical volumes 
that the host can access, and for the port adapter to map this 
limited range of LUNs to the limited set of logical volumes 
that each host can access. The host therefore does not need 
to deal with a large number of possible volumes, and 
minimal modification of the host programming is needed 
when a host is networked to the data storage subsystem. 
Instead of specifying a logical volume number when 
requesting access to a logical storage volume, the host 
specifies a LUN, and the port adapter receiving the storage 
access request translates the specified LUN to a correspond- 
ing logical volume number. There can be a different map- 
ping of LUNs to logical volume numbers for each host or 
host controller port. 

As shown in FIG. 19, the mapping of LUNs to logical 
volume numbers for a volume group name is specified by the 
entries in the volume list 210 associated with the volim^e 
group name. Each entry in the volume list 210 includes a 
LUN in the volume group and its corresponding logical 
volume number (VOL__NO.). The first entry 211 in the 
volume list, for example, maps LUN 1 to logical volume 
number 8. 

In practice, it is desirable to assign ranges of contiguous 
LUNs to the volume groups or hosts. These ranges of 
contiguous LUNs, for example, are evident when the LUNs 
in the volume list are sorted by LUN, for example as shown 
in FIG. 19. In many cases, each range of contiguous LUNs 
corresponds to a range or vector of logical volume numbers. 
Therefore, in a data processing system having a large 
number of LUNs per host and an even larger number of 
logical volumes, it may be desirable to specify the LUN to 
logical mapping as a number of ranges of contiguous LUNs 
and corresponding vectors of logical storage volume num- 
bers. 

As shown in FIG. 20, for example, each entry in the 
volume list 220 associates a respective range of contiguous 
LUNs with a vector of logical volume numbers. Each entry 
includes the first LUN in the range, the number (N) of LUNs 
in the range, the beginning logical volume number in the 
associated vector of logical volume numbers, and the stride 
(S) of the vector. The first entry 221 in the volume list 220, 
for example, specifies a first LUN of one, a number (N) of 
three, a beginning logical volume number of eight, and a 
stride (S) of two. This maps the sequence of contiguous 
LUNs (1, 2, 3) to the sequence of logical volume numbers 
(8, 10, 12), and therefore the first entry 221 in the volume list 
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220 of FIG. 6 encodes the same information as the first three 
entries in the volume hst 210 of FIG. 19. 

To find whether a specified LUN is within the map of any 
entry in the volume list 220, the specified LUN value is 

5 compared to the LUN value in the entry, and if it is less than 
the LUN value in the entry, the specified LUN is not within 
the map of the entry. If the specified LUN value is greater or 
equal to the LUN value of the entry, then the specified LUN 
value is compared to the LUN value in the entry plus the 

10 value of N in the entry. If the specified LUN value is less 
than the LUN value in the entry plus the value of N in the 
entry, then the specified LUN is within the map of the entry; 
otherwise, it is not. If the specified LUN is within the map 
of the entry, then its corresponding logical storage volume 

15 number is computed as: 

LOGICAL_VOLUME_NrO.=MAF_V01 NO.+(SPEC_LUN- 

MAP_LUN)*S 

where MAP_VOL_J^O. is the VOL_JiO in the map entry, 

20 SPEC_XUN is the specified LUN value, and MAP_LUN is 
the LUN value in the map entry. 
VOLUME PARTITIONING BY VIRTUAL PORTS 
As described above with reference to FIG. 7, the port 
adapters can be programmed to provide a "Report LUNs" 

25 command that vdll report to each host only the LUNs or 
logical storage volumes assigned to the host. In other words, 
a host would not normally have the capability of seeing the 
LUNs or logical volumes assigned to another host. This 
offers some security, but it is incompatible with the conven- 

30 tional "Report LUNs" command of the Fibre Channel stan- 
dards. In a Fibre Channel network, if a conventional "Report 
LUNs" command is used to discover LUNs, all ports will 
report back all of their LUNs. 
The method of FIG. 7 also has the disadvantage that a 

35 significant amount of port adapter processing time is spent 
in managing variable-length volume lists or very long bit- 
maps. The method of FIG. 7 fiirther has the disadvantage 
that the entire group of volumes for a host controller must be 
flagged as shared if only one of the volumes in the group are 

40 shared, which increases the access time of the private 
volumes in the group. It would be desirable to use a 
predefined, fixed-length format for the lists that are fre- 
quently accessed if this would not waste port adapter 
memory or unduly limit the set of logical volumes that could 

45 be assigned to each host. For a host controller having both 
shared and private volumes, it would be desirable to asso- 
ciate more than one group of volumes to the host controller, 
including one or more groups of all private volumes and one 
or more groups of all pubhc volumes, so that each group can 

50 be separately flagged as private or public. 

The method of virtual ports overcomes these disadvan- 
tages in a way that is compatible with the Fibre Channel 
specifications. In accordance with the method of virtual 
ports, the storage subsystem presents to the Fibre Channel 

55 network a set of "virtual" Fibre Channel ports that do not 
really exist on the network. A set of logical volumes is 
assigned to each of the virtual ports. The logical volumes 
within each set are accessible from the virtual port through 
at least one physical port of the storage subsystem. This 

60 physical port is therefore a fabric port and the storage 
subsystem provides a virtual switch from the physical port 
to each of the virtual ports accessible through the physical 
port. In particular, the physical port is a Fibre Channel 
FL_J*ort if it is in a loop of the Fibre Channel network, or 

65 it is a Fibre Channel E_Port if it is connected to a switch, 
or otherwise it is a Fibre Channel F_J*ort. The port adapter 
providing the physical port is programmed to function as an 
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FL_J*ort, E _Port or F_JPort by responding to host login not appear as physical nodes anywhere in the cached storage 

commands and assigning S_lDs; by responding to conven- subsystem 20, the ports 240, 341 arc called virtual ports, and 

tional Fibre Channel Report LUNs commands for reporting the switches 238 and 239 arc called virtual switches. 

LUNs assigned to the virtual ports; and by responding to As far as the data network 21 is concerned, the virtual 

routing instructions from a host for routing data access 5 Ports 240 and 241 function in a fashion similar to physical 

requests to a specified virtual port and a specified LUN of Ports in the data network. Hie virtual ports are assigned 

the virtual port respective port names, WWNs, and S_IDs, and requests 

When using' the method of virtual ports for volume °ther nodes in the network are routed to them through 

partitioning, one or more virtual ports are assigned by the '."^P"^"^* ^"^^f, ^^^''^^^ ^38 239. For example the 

. J • • ^ * 4 i_ f t- * u • * Virtual ports respond to Report LUN requests in a fashion 

system admimstrator to each of the hosts having access to lo ^.^^^^^ ^ j/^^^^ ^ ^^^^^ ^^^^^^^ 

one or more of the vutual ports Preferably logical storage ^-^^^^^ switches, the random access memory 236 is 

volumes can be accessed through a single virtual port by no programmed with switch definitions 242 and also stores 

more than one assigned host This simplifies the access switch state information 243. The switch definitions 242, for 

control or filtenng function of the storage subsystem, and example, include the respective WWNs of the virtual 

does not unduly restrict the sets of logical volumes that can 15 switches 238 and 239, and the switch state 243 includes the 

be accessed since a sufficiently large number of virtual ports S_IDs assigned at any given time to the virtual ports 240 

can be created. A fixed-length format can be used for storing and 241. The microcode 237 is also programmed to provide 

the lists of hosts, virtual ports, and LUN to logical storage respective name servers 244 and 245 which provide nodes 

volume mapping information for each virtual port because a linked to the respective ports 231 and 232 with limited 

variable number of virtual ports can be assigned to each 20 access to the switch definitions 242 and switch state 243. In 

host. If a host needs more logical storage volumes than can particular, the name servers can provide the respective 

be included in the volume list for a single virtual port, names, WWNs, and S_JDs of all the virtual and physical 

another virtual port can be created and assigned to the host, ports of the virtual switches. 

Moreover, each virtual port can be accessible through any The random access memory 236 is further programmed 

desired number of the storage subsystem adapter ports 25 with volume access and mapping information 246. The 

defined as FL_Ports, E_Ports, or F_Ports. The virtual port volume access information indicates a respective set of 

is made accessible by storing in the memory of the port storage LUNs that any host can access by requests addressed 

adapter the access and mapping information for the virtual to the virtual ports 240, 241. The volume mapping infor- 

porl. mation indicates respective logical volumes mapped to the 

A host uses conventional Fibre Channel commands and 30 virtual ports 240, 241. The volume access and mapping 

protocols for sending requests to its assigned virtual port or information for each of the virtual switches 238, 239 could 

ports. Since the Fibre Channel standards do not restrict the be the same or it could be different. For example, it could be 

ability of a host to send requests to all of the ports Unked by the same to permit any host to be disconnected from any one 

the Fibre Channel network, there must be a mechanism for of the network loops 42, 44 and connected to the other loop 

the system administrator's assignment of the virtual ports to 35 without any change in the storage access privileges or 

the hosts to be communicated to the hosts, and the hosts procedures of the host. The set of logical storage volumes 

must use this information to direct their storage access mapped to different virtual ports can be the same or different, 

requests to the virtual ports to which they are assigned. This For example, the set of logical storage volumes mapped to 

assignment information must also be used by the host if the two virtual ports can be the same to permit two hosts to share 

host has an operating system that permits the host to boot 40 the set of logical storage volumes mapped to the two virtual 

from a logical volume in storage Unked by the Fibre Channel ports. 

network to the host, or that permits the operating system of With reference to FIG. 22, there is shown a data process- 

the host to collect information about the logical storage ing system having a cached storage subsystem 250 and four 

volumes that it can access. In other words, the operating host computers 251, 252, 253, 254 hiied to the cached 

system routine that searches for the storage volumes that are 45 storage subsystem by a data network 255. In this example, 

accessible to the host must send Report LUNs commands to the hosts are linked by four loops 256, 257, 258, 259 to 

only the virtual ports assigned to the host and not to the respective network port adapters 260 and 261 of the cached 

virtual ports assigned to other hosts. data storage subsystem. Each port adapter has two physical 

With reference to FIG. 21, the port adapter 36 of the ports designated as "A" or "B". The physical port 262 of the 

cached storage subsystem 20 is shown having been pro- 50 port adapter 260 is an "A" port linked to the loop 256, the 

grammed to provide virtual ports for access to respective physical port 263 ofport adapter 260 is a B port linked to the 

groups of logical storage volumes. The port adapter 36 has loop 257, the physical port 264 ofport adapter 261 is an "A" 

two physical ports 231 and 232 provided by port circuitry port finked to the loop 258, and the physical port 265 ofport 

233 and 234, respectively. The port circuitry performs adapter 261 is a "B" port linked to the loop 259. The port 

seriafizing, framing, sequencing, flow control, and coordi- 55 adapters 260, 261 are programmed to provide respective 

nation of protocols and services in accordance with the Fibre virtual switches 266, 267 linking their "A" and "B" physical 

Channel standards. The port adapter 36 further includes a ports to a set of virtual ports 268, including a respective 

microprocessor 235 and a random access memory 236. The virtual port VPl, VP2, VP3, VP4 assigned to each of the 

microprocessor 235 executes microcode 237 in the random hosts 251, 252, 253, 254. Each of the port adapters 260 and 

access memory 236. In particular, the microprocessor 235 is 60 261 is programmed with respective volume access informa- 

instructed by the microcode 236 to handle Fibre Channel tion 269, 270 which can be identical to permit any of the 

requests received by the port circuitry 233 in such a way that hosts 251, 252, 253, 254 to be disconnected fi"om any one of 

there appears to be a respective switch 238, 239 in the the loops 156, 157, 158, 158 and reconnected to any other 

storage controller 27 connecting each of the ports 123, 131 of the loops without any change in the storage access 

to a respective set of ports 240, 241 between the ports 123, 65 privileges or procedures of the host. 

131 and the storage volumes (28, 29, 30, and 31) in the With reference to FIG. 23, there is shown an example of 

cached storage subsystem 20. Since the ports 240, 241 do the volume access and mapping information 269 of FIG. 18. 
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The volume access and mapping information 246 of FIG, 21 
can have a similar format. The vohime access and mapping 
information 269 includes a virtual port host table 281 listing 
each host having access rights through a virtual switch 
controlled with the volume access and mapping information, 
and a virtual port mapping table 282 listing each virtual port 
accessible through the virtual switch controlled with the 
volume access and mapping information. Separate tables are 
used because each host listed in the host table can have more 
than one assigned virtual port. Also included in the volume 
access and mapping information 269 are optional lists 283 of 
indices to the virtual port identifiers in the virtual port 
mapping tabic 282 assigned to each host in the virtual port 
host table 281. The lists 283 are optional because the 
information in the lists could be obtained by scanning 
through an entire column of host indices in the virtual port 
mapping table. The lists 283 are not needed for handling a 
storage access request by a host. The lists 283 are used for 
quickly responding to a host when the host requests a report 
of the virtual ports from which it can access logical storage 
volumes. It is desirable to compile the lists by scanning the 
host index column of the virtual port mapping table and store 
the lists if a large number of hosts will be requesting the 
information frequently, for example, if the hosts login to the 
network frequently and request the information during each 
network login. The lists 283 in total have a limited memory 
requirement because each virtual port in the virtual port 
mapping table can have only one assigned host, so that in 
total the lists 283 include no more than one occurrence of a 
virtual port index for each of the virtual ports listed in the 
virtual port mapping table. 

Referring to FIG. 24, there is shown a format for the 
virtual port host table 281. The table 282 includes a unique 
row for each host controller port from which a host can 
access a virtual port defined in the virtual port mapping table 
(282 of FIG. 23). The table 281 includes a column for the 
HOST JD of the host controller port, a flag PORT A/B 
indicating whether the host controller port is linked to the 
physical "A" or "B'' port of the port adapter programmed 
with the table 281, the WWN of the host controller port, the 
S _ID of the host controller port, a V„PORT INDEX which 
is a first index to a row of information in the virtual port 
mapping table (282 in FIG. 23) to which the host controller 
port has access through the port adapter, and a V__PORT 
LIST POINTER which is zero if there is only one V_PORT 
associated with the host controller port and otherwise points 
to a list of additional virtual port mapping table indices to 
rows of information about additional virtual ports to which 
the host controller has access through the port adapter. 

The HOSTED, for example, is the IP address of the host 
controller port. The HOST_ID could have the same format 
as the volume group name of the table in FIG. 5; i.e., a host 
name and controller sequence number. 

If the optional lists of indices to the virtual port table are 
not used, the V_J>ORT LIST POINTER would sunply be a 
flag indicating whether or not there is more than one virtual 
port associated with the host controller port. If there is only 
one, it is found in the V_PORT INDEX column of the 
virtual port host table. If there is more than one, then the 
entire list can be found by scanning the HOST INDEX 
column of the virtual port mapping table 282 for entries 
having a HOST INDEX matching the index of the row in the 
virtual port host table containing the information for the host 
controller port. 

Referring to FIG. 25, there is shown a format for the 
virtual port mapping table 282. The table 282 includes a 
unique row for each virtual port accessed through the port 
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adapter. The table 282 includes a column for the V_PORT_ 
ID of the virtual port, a HOST INDEX to a row of the virtual 
port host table for the host controller port associated with the 
virtual port, a private/shared flag, and a LUN TO LOGICAL 

5 VOLUME MAP specifying the set of LUNs at the virtual 
port, the set of logical storage volumes accessible from the 
virtual port, and the mapping between the LUNs and the 
logical storage volumes accessible from the virttial port. The 
V JORT_ID is a primary key for the table 282. The table 
282, for example, is sorted by the V_PORT__ID or has an 
associated hash table directory to facilitate searching of the 
table for a specified value of the V_PORT_ID. The 
VPORTJD could be an IP address for the virtual port. 

The LUN TO LOGICAL VOLUME MAP in each row of 
the table 282 could use the format of FIG. 19 or FIG. 20 with 

15 a fixed number of either the entries shown in FIG. 19 or the 
entries shown in FIG. 20. Since there would be a fixed 
number of possible entries of the format of FIG. 19 or FIG. 
20 but less than all of the entries might be used at any given 
time, the unused entries could be filled in with a null value 

20 for the LUN, such as a zero LUN value. The first entry 
would always be used, and any other entries used would be 
contiguous with the first entry, so that aU of the entries used 
could be found by scanning and testing the LUN value in the 
entry. Alternatively, the LUN TO LOGICAL VOLUME 

25 MAP for each virtual port could be preceded with an integer 
value indicating the number of entries used in the map at any 
given time. 

The LUN TO LOGICAL VOLUME MAP in each row of 
the table 282 could be a bitmap in the form of a LUN to 

30 logical volume mapping matrix. The logical OR of all the 
rows of such a matrix would be a bitmap indicating aU of the 
logical volumes accessible from the virtual port. The logical 
OR of all the columns of such a matrix would be a bitmap 
indicating aU of the LUNs accessible from the virtual port. 

35 The use of such a mapping matrix would not be a practical 
alternative if there were a large number of virtual ports, 
hosts, possible LUNs, and logical volmnes, since the num- 
ber of bits of memory for storing such all of the mapping 
matrices would be the product o the number of virtual hosts, 

40 the number of possible LUNs, and the number of logical 
volumes. 

Referring to FIG. 26, there is shown a flowchart of a 
routine executed by the microprocessor of the port adapter 
to provide a service for reporting the virtual ports accessible 

45 to a host controller port through the port adapter. This 
service could provide such a report when a host controller 
logs in to the data network, or when a host controller port 
requests the information from a name server of the virtual 
switch provided by the port adapter. In a first step 301, the 

50 microprocessor searches the virtual port host table for an 
entry includmg a specified HOSTED. In step 302, execu- 
tion branches to step 303 if a table entry is not found for the 
specified HOST_JD. In step 303, the port adapter reports 
that there are no V_PORTS accessible to the host through 

55 the port adapter, and the routine is finished. 

In step 302, execution continues to step 304 if a table 
entry is found for the specified HOST_JD. In step 304, the 
port adapter reports that the V_PORT of the VJORT 
index in the table entry is accessible to the host. In other 

60 words, the microprocessor reads the VJORT INDEX from 
the row of the virtual port host table containing the specified 
HOST„ID, and then indexes the virtual port mapping table 
with the V_PORT INDEX to find the first V_PORT_ID 
associated with the HOST_ID. In step 305, the V_J>ORT 

65 LIST POINTER is compared to zero, and if it is zero, then 
the routine is finished. Otherwise, execution continues from 
step 305 to step 306. 
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In step 306, the V_PORT list pointer is used to access the 
hst of additional indices to accessible V_PORTS in the 
virtual port mapping table. Finally, in step 307, the port 
adapter reports that the indexed V_PORTS are accessible to 
the host through the port adapter, and the routine is finished. 

Referring to FIG. 27, there is shown a flowchart 320 of a 
routine executed by the microprocessor of a port adapter 
when the port adapter receives from a host controller port a 
volume access or Report LUNs request to a specified virtual 
port. To ensure compliance with the Fibre Channel 
standards, this Report LUNs request might be different from 
and in addition to the standard Report LUNs command. The 
Report LUNs request of FIG, 27 reports the storage LUNs 
accessible to a specified host controEer port, in contrast to 
the standard Report LUNs command which could report all 
LUNs accessible from a virtual port including all storage 
LUNs accessible from the virtual port by any of the hosts. 
In response to a standard Report LUNs command directed to 
a virtual port, the port adapter would search the virtual port 
mapping table 282 of FIG. 25 for the V JORT^ID speci- 
fied by the Report LUNs command to find the table entry 
including the V_J^ORT_JD, and then report all of the LUNs 
included in the LUN TO LOGICAL VOLUME MAP in the 
table entry. 

In a first step 321 of the flowchart 320, the microprocessor 
searches the virtual port mapping table for the entry of the 
virtual port specified by the host. If such a table entry is not 
found, then execution branches from step 322 to step 323. In 
step 323, the request is denied, and the routine is finished. If 
such a table entry is found, then execution continues from 
step 322 to step 324. In step 324, the microprocessor obtains 
the HOST_INDEX of the entry of the virtual port mapping 
table. In step 325, the virtual port host table is indexed with 
the HOST_JNDEX. 

In step 326, the HOST_ID of the host controller port 
requesting access is compared to the H0ST__1D in the 
indexed entry of the virtual port host table. If the HOST_ID 
of the host controller port requesting access is not equal to 
the HOST_JD in the indexed entry of the virtual port host 
table, then execution branches from step 326 to step 323. In 
step 323 the port adapter denies the request, and the routine 
is finished. If the HOST_ID of the host controller port 
requesting access is equal to the HOST_JD in the indexed 
entry of the virtual port host table, then execution continues 
from step 326 to step 327. 

In step 327, the microprocessor checks whether the port 
adapter's physical port "A" or "B** from which the request 
was received is the same as the physical port "A" or "B" 
indicated by the PORT A/B flag in the indexed entry of the 
virtual port host table. If not, then execution branches from 
step 327 to step 328. In step 328, execution branches from 
step 328 to step 323 to deny the request if a "fixed port 
option** is selected. The "fixed port option** would be 
selected if it is desired for a host controller port to access the 
specified virtual port only through a specified one of the 
physical "A** or "B*' ports of the port adapter. This option 
could apply or not apply to all of the host controller ports, 
or the option could be specified by a flag (not shown) in each 
entry of the virtual port host table to selectively apply the 
option to each host controUer port. For example, the option 
could be selected for desktop workstations, and not be 
selected for portable host computers. If the fixed port option 
is not selected, then execution continues from step 328 to 
step 329. In step 329, the microprocessor switches the PORT 
A/B flag in the table entry. Execution continues from step 
329 to step 330 of FIG. 27. Execution also continues from 
step 327 to step 330 of FIG. 27 if the request was received 
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from the port adapter's physical "A" or "B" port indicated 
by the PORT A/B flag in the indexed entry of the virtual port 
host table. 

Referring to FIG. 28, in step 330 the S_JD from the 

5 request is compared to the S_ID in the indexed entry of the 
virtual port host table. If the S__1D of the request does not 
match the S_ID in the indexed entry, then execution 
branches from step 330 to step 331 to recover from the 
tmreported state change. If the port adapter cannot verify the 

10 new S_JD in the request, then the request is denied; 
otherwise, the S_JD value in Uie indexed entry is changed 
to the new value in the request, and execution continues in 
step 332. Execution also continues from step 330 to step 332 
if the S_ID from the request matches the S _JD in the 

15 indexed entry. 

In step 332 execution branches to step 333 for processing 
a "Report LUNs" request from a host controller port. In step 
333, the port adapter reports to the host controller port the 
LUNs in the LUN TO LOGICAL VOLUME MAP of the 

20 indexed entry of the virtual port mapping table, and the 
routine is finished. Execution branches from step 332 to step 
334 for processing a storage access request from a host 
controller port. In step 334, the microprocessor searches the 
LUN TO LOGICAL VOLUME MAP of the indexed entry 

25 of the virtual port mapping table for the specified LUN to 
access. If the LUN to access is not found, then execution 
branches from step 335 to step 336. In step 336, the port 
adapter reports to the host controller port that the specified 
LUN to access is unknown, and the routine is finished. 

30 Execution continues from step 335 to step 337 if the LUN 
to access is found in the LUN TO LOGICAL VOLUME 
MAP of the indexed entry of the virtual port mapping table. 
In step 337, the private/shared flag is inspected for the 
indexed entry of the volume access table. If the private/ 

35 shared flag is set, then execution continues from step 337 to 
step 338. In step 338, the port adapter accesses the logical 
volume mapped to the LUN specified by the host controller, 
and the routine is finished. If the private/shared flag is not 
set, then execution branches from step 337 to step 339 to 

40 access locking information in the cache memory for the 
logical volume mapped to the LUN specified by the host 
controller. If the volmne is private to the host controller, then 
access is permitted, and execution branches from step 340 to 
step 348 to access the volume. If the volume to access is 

45 pubUc and is already locked in a fashion incompatible with 
the access requested by the host (e.g., the volume is already 
write locked and the host controller requests a read or a write 
access, or the volume is already read locked and the host 
controller requests a write access) then access not presently 

50 permitted. The host controller's S _JD is placed on a wait 
hst, in order to notify the host controller when the logical 
volume becomes available; execution branches from step 
340 to step 341 to temporarily deny access to the volume, 
and the routine is finished. If the volume to access is public 

55 and is not locked or is locked in a fashion compatible with 
the requested access by the host controller (e.g., the volume 
is already read locked and the host controller requests a read 
access), then a lock is granted to the host controfler, and 
execution branches from step 340 to step 338 to access the 

60 volume, and the routine is finished. 

GRAPHICAL USER INTERFACE FOR VIRTUAL 
PORTS 

A conventional graphical user interface (GUI) for a 
cached storage subsystem of the type shown in FIG. 1 
65 includes a grid of logical volumes to storage adapter ports. 
At each intersection of the grid, the target/LUN is assigned. 
This provides a mechanism for the system administrator to 
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set and view the mapping of LUNs to logical storage tional functions. For security, password protection is desir- 

volumes and the storage adapter ports used for accessing the able on a user and/or host level. For flexibility, it is desirable 

physical storage volumes that make up the logical storage to have be able to modify or view a host^s volmne configu- 

volumes. Referring to FIG. 29, there is shown an example of ration from local or remote hosts. The systems administrator 

how the mapping of LUNs to logical storage volumes can be 5 should have the abUity to read and write the physical and 

incorporated into a GUI for a cached storage subsystem that virtual port names of storage subsystem as defined in the a 

uses virtual ports. It is stiU possible to use a grid for defining configuration database. The configuration database should 

the relationship between logical volimies, LUNs, and stor- contain flags that indicate if a volume can be shared. If 

age adapter ports, but the GUI display screen is partitioned sharing of a volume is forbidden, the graphical user interface 

into groups of V _J*ORTs by physical port of the port lo does not allow it to be allocated to more than one host. If it 

adapters. In this example, each intersection allows the can be shared, the systern. administrator is notified of this 

definition of the LUN only, FIG. 29, for example, shows a upon configuration creationsfGf^shjj^edlvt^lSmes^ 

single grid 345 for the logical volumes accessible by a host The graphical user interface may recognize an "Install" 

controller port linked to the physical port A of a port adapter command to be use when a new host controller port is 

I addressing LUNs at a virtual port 1. A similar grid could 15 introduced. The install command writes the host's configu- 

be displayed for each virtual port defined in the storage ration information into the volume configuration database, 

subsystem. The graphical user interface may recognize a "Replace'* 

Referring to FIG. 30, there is shown a GUI display screen command to replace a host controUer port. The graphical 

for permitting the system administrator to set up the rcla- user interface maintains a list of the WWNs for each 

tionship between logical storage volumes of the storage 20 controller port on the host. The graphical user interface also 

subsystem (the volume source) and the volumes addressed keeps a historical database of all WWNs ever known to be 

by a host (the volume user). In this example, the GUI display networked to the storage subsystem. Using this information, 

screen includes, on the left, a list 346 in outline form of the graphical user interface can determine that a known host 

storage subsystem compooents down to a set of logical controller port is not bound to a configuration and also a 

volumes for one virtual port, and on the right, a list 347 in 25 configuration that contains a new host controUer port that 

outhne form of host components down to a set of LUNs as did not previously exist on the host. As described above with 

addressed from one host controller port. The "bus" in the reference to FIG. 18, the system administrator should be 

right column refers to a host controller, and the "target" in involved in the introduction of any new host controller ports 

the right column refers to a port of the host controller. The into the configuration. 

display starts out with a list of storage subsystems and a list 30 The graphical user interface may recognize a "Configu- 

of hosts linked by the data network. The system adminis- ration" command to enter or modify a host's volimie con- 

trator selects a storage subsystem or host by chcking on it figuration information for a local or remote host. This 

with a pointing device such as a mouse interfaced to the configuration information should be stored in the configu- 

service processor, and expand the list to the next lower level ration database in the storage subsystem, 

by double clicking on a selected item of the list. By 35 The graphical user interface should recognize a "remove 

expanding the lists down to the port adapter and host from service" command for use when removing a host or 

controller port levels, the system administrator clicks on a host controller from service. In response to this command, 

particular physical adapter port in the left colunm to get to the graphical user interface deletes the associated volume 

virtual ports and logical volumes for the particular adapter configuration information from the database, 

port, and then clicks on a particular controller bus and target 40 The graphical user interface may recognize a "View 

to get the LUNs as addressed by the host. The system Configuration" command, and respond by displaying a 

administrator selects an unallocated virtual port in the left schematic diagram of the fabric or loop in the data network, 

column for a physical adapter port and then selects a host and displaying attribute information (such as port WWN) 

controUer port in the right column to allocate the host according lo its availability. 

controUer port to the virtual port. The system administrator 45 The graphical user interface may provide separate dis- 

could then select a logical storage volume, or selected range plays of the assignments of the virtual ports to the host 

of volumes, and select a LUN or range of LUNs as addressed channel ports, the mappings of LUNs to logical volumes, 

by the host controUer port, to establish the LUN to logical and the allocation of the logical volumes to the storage 

volume mapping. For example, in FIG. 30, the GUI display adapter ports and to the storage devices, 

has drawn a line 348 between the selected logical storage 50 One the system administrator defines the virtual ports and 

volume VOLl and the selected LUN 2 to show that such a mappings between the logical volumes and LUNs, the 

mapping has been established. The system administrator storage subsystem can automatically assign network 

could also select an item on either List and "collapse" the list addresses, WWNs and S_IDs to the virtual ports, and obtain 

to go back up to the level in the outline above the selected the WWNs and S_IDs of the host controUer ports when the 

item. For data security, any unallocated logical volume 55 host controller ports log in to the network. This could be 

shoxild be re-formatted or erased of any pre-existing data done in a fashion similar to that described above with respect 

before being allocated. to FIGS. 16 to 18, by setting unknown host controller port 

The system administrator could select an item on either WWNs and S^Ds to null values, 

list and select a "properties" option to display properties of Since a cached storage subsystem of the type shown in 

the selected item. For example, the grid 345 of FIG. 29 could 60 FIG. 1 typically has a smaU number of physical adapter 

be one of the properties of the virtual port 1. The properties ports, such as 16, the method of virtual ports can be 

of a logical storage volume would include the host controller introduced in such as system using a small number of 

ports having access to the logical storage volume, and the V_PORTs per physical ports. For example using only 4 

paths or adapter ports and virtual port through which the host V_J*ORTs per physical port will allow the cached data 

controUer ports can access the logical storage volume. 65 storage system to 64 ports. Once users would become 

The preferred embodiment of the graphical user interface familiar with the concept of the virtual ports, the number of 

used by the system administrator has the folbwing addi- virtual ports permitted per physical port could be increased, 
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and additional facilities could be introduced for volume 
configuration and site management of the Fibre Channel 
network. These facilities could permit involvement of the 
host in allocating and de-allocating logical storage volumes 
and changing the configuration and mapping of LUNs to 5 
logical storage volumes. 

HOST INTVOLVEMENT IN VOLUME CONFIGURA- 
TION AND MAPPING. 

A number of facilities could be used to permit host 
involvement in the storage voltmie configuration and map- lO 
ping. The facilities should not assimie the existence of 
"trusted" hosts. The identity of a host requesting a change in 
the volume configuration and mapping should be authenti- 
cated. 

A primary copy of the configuration information for the 15 
volumes accessible to a host is kept in the storage subsystem 
and on the host. The host should be able to access the 
primary copy on the storage subsystem if a host's local copy 
is not available. However, an exception to this would be a 
host that is responsible for storing the primary copy of 20 
another host. The configuration information should be 
accessed through read and write commands and should be 
protected against accidental writes. For example, the con- 
figuration information is stored in a predefined logical 
volume, such as a volume accessed at LUNO, that functions 25 
as a gatekeeper device. 

No host should be able to gain access to another host's 
volume unless sharing is enabled. Sharing should be per- 
mitted when desired. For example, the volume attributes and 
locking information (89 in FIG. 7) associated with the 30 
logical volumes includes a flag for each volume to indicate 
whether or not sharing of the volume is permitted. This flag 
is inspected when the graphical user displays the logical 
volumes available for allocation, or when a host requests 
allocation of a volume. Ahost controller driver program also 35 
may limit (or filter) the nuihber of volumes that can be seen 
by the host operating system (and thus the host applications) 
by using the information contained in the configuration 
database. 

Each host should be allowed to use its own volume 40 
address space (LUNs) regardless of the volume address 
space used in the storage subsystem. This is the function of 
mapping LUNs to logical volumes, as described above. 

Management of the configuration information should be 
permitted- from any location within the data network enter- 45 
prise. A system administrator should not be required to log 
into any host that is the target of the configuration changes. 

The facilities should work well with a variety of existing 
host and storage system components, for example, by pre- 
serving SCSI conventions, and supporting both IP and SCSI 50 
conventions within a single host controller. 

The facilities should provide for installation, volume 
reconfiguration, topology reconfiguration, boot from local 
disk, boot from Fibre Channel disk, normal I/O operation, 
replacement of a controller from existing host, replacement 55 
of a controller known in the current configuration with an 
unknown host during installation, and reuse of a controller 
known in the current configuration as a replacement con- 
troller. Suitable installation, volume configuration, normal 
I/O operation, and controller replacement facilities have so 
been described above. 

Topology reconflguratioD occurs whenever a connection 
is added, deleted, or modified in the data network. Some of 
the types of problems that can occur is for the S_JD of a host 
controller port to change. Therefore, the ports should login 65 

to the data storage subsystem to register the new S IDs. 

Otherwise, the port adapters may recognize and recover 
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from unreported state changes, as described above. A host 
controller port may become imlinked from a physical "A" 
port and relinked to the physical "B" port. If the "portable 
host" option is selected, this causes no difficulty. A host 
controller port may become unlinked form the physical port 
of a first port adapter and relinked to the physical port of a 
second port adapter. Unless the same virtual port is defined 
as accessible to the host controller port in each of the port 
adapters, this will catisc the second port adapter to reject 
host requests. In this case, it is necessary to transfer the 
virtual port definitions and mappings fixtm the first storage 
adapter to the second storage adapter. 

The facilities that can be used by a host for booting are the 
routine described above for reporting to a host the virtual 
ports available to the host, and the routine described above 
for reporting to the host the LUNs available to the host from 
a virtual port. These routines cotild be programmed into each 
port adapter. Alternatively, a host could read the primary 
copy of the configuration in formation in the "gatekeeper^' 
volume of storage in the storage subsystem. In any case, the 
host must be programmed to seek out the LUNs that it can 
access. For example, a host controller routine first powers up 
and logs in to the network. Then a mapping driver in the host 
is loaded into the host's memory, and the mapping driver 
contains the network addresses of the data storage sub- 
system adapter ports to access, and contains instructions for 
sending the commands to these adapter ports to obtain the 
LUN information or read the primary copy of the configu- 
ration information in the storage subsystem. The host oper- 
ating system invokes the mapping driver to obtain the LUNs 
accessible to it. 

It is also desirable to provide the host with the capability 
of using a logical volume in the storage subsystem as a "boot 
disk." Booting over Fibre Channel allows support of disk- 
less systems and, more importantly, provides reliability and 
a means for disaster recovery. Booting over the Fibre 
Channel is especially useful when the host is a commodity 
server. In this situation, the storage subsystem can provide 
the disk storage for a plurality of the commodity servers. The 
commodity servers can handle wide area network commu- 
nication protocols with other hosts such as workstations, and 
file system management for file systems stored in the logical 
voltunes of the storage subsystem. 

The^e of a logical volume in the storage subsystem as 
a "boot disk" increases reliability of a host because the 
standalone disk in a typical server represents the component 
with the worst mean time before failure. In the past, the 
system administrator has been willing to treat a local disk 
failure as a server failure. The storage subsystem, however, 
has a fault-tolerant architecture and uses techniques such as 
mirroring of the storage devices or RAID so that a logical 
volume in the storage subsystem has a much higher mean 
time before failure than the typical server or server disk. The 
storage subsystem also enhances disaster recovery capabili- 
ties because it is easy to recover from the destruction of a 
commodity server simply by plugging in a replacement 
commodity server having the same hardware configuration. 

A host computer boots from a present disk address. This 
is accoinphshed through one of the following methods. In 
the PC environment, the host controller is a SCSI controller 
that must act like an IDE controller and answer all interrupts 
that are targeted for the disk. The host controller uses a 
specific SCSI target that has either been hardwired in the 
design of the host controller stored in nonvolatile memory 
on the host controller. In other environments, the mother- 
board of the host typically contains the SCSI address to use 
in non-volatile memory. The address must be available 
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before any information on a disk is available to be read. This 
means that the nonvolatile memory must be used either on 
the motherboard or the host controller. 

The address of the boot disk in the Fibre Channel envi- 
ronment is a storage subsystem port WWN and a storage 5 
subsystem LUN. The nonvolatile memory must store a 
complete path to the boot volume, including the SCSI 
address to be used by the host as well as the storage 
subsystem WWN and LUN. 

To support booting from a storage subsystem volume, the lO 
host controller is provided with a facility to read and write 
the boot information. This information should also be saved 
in the storage subsystem volume configuration database in 
order that a replacement host controller can be loaded with 
the correct information during configuration. To facihtate 15 
this, the read and write boot commands would each use the 
following stmcture: 

struct (int64 hba__wwn; /* which host controller port to 
address with this cmd */ 

int bus; /* the value for the host bus */ 20 
int target; /* the value for the host target */ 
int lun; /* the value for the host lun */ 
int64 symm_wwn; /* the value for the storage sub- 
system port WWN */ 
int symm_lun; /* the LUN to use on the storage 25 
subsystem port */ 
HOST REQUESTS FOR DYNAMIC ALLOCAnON 
AND DE-ALLOCATION OF LOGICAL VOLUMES 

After an initial configuration by the system administrator 
and during normal operation of the data processing system, 30 
a host application may need additional storage volumes, or 
may no longer need storage volumes allocated to it. To avoid 
significant involvement of the system administrator in this 
situation, the port adapters of the storage subsystem can be 
programmed to recognize "mount" and "urunount" com- 35 
mands from the host controller. These commands can be 
similar in form and function to the Unix mount/unmount 
commands, and would be sent to the storage subsystem 
gatekeeper (e.g., at LUNO). A command line for the mount 
command, for example, has the form: 40 
storage_subsystem_mount volume_group__name 

host_controller host_lunl . . . host_JunN 
A command line for the unmount command, for example, 
has the form: 

Host controller ID (the value assigned by the switch at 

login time) 
Hostname IP address 
Volume group name 

Host LUN 1 50 
Host LUNn 

In the storage subsystem, the gatekeeper facility responds 
to the mount command by allocating free logical storage 
volumes to the specified LUNs, and creating an entry in the 55 
volume access table or tables for the specified volume group 
name and the LUN to logical volume mappings. The entry 
would include the host controller port*s S_ID and WWN. 
The host could specify attributes for logical volume to be 
allocated to each volume, such sharing enabled, or sharing 60 
enabled for read-only access. In this example, the volumes 
allocated to the host would all be private, and the private/ 
shared flag for the volume group name would be set. The 
system administrator would set up in advance any assign- 
ment of already volumes to be ^ared between different host 65 
controller ports. It would be possible, however, to have an 
option whereby one host controller port could request and 
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obtain mounting of volumes shared with another host con- 
troller port. If LUN to logical volume mapping is used, this 
option could be limited to sharing between two ports of the 
same host controller, or two ports of the same host, because 
such an option assumes that the LUN to logical volume 
mapping would be the same for the two host controller ports. 
In response to such a command, the gatekeeper would check 
whether the attributes specified in the command for the 
LUNs to be assigned (such as shared, shared for read-only 
access) match those of the already allocated LUNs. 

The mount command could also have an option to define 
the volume group name as local to just the port adapter that 
receives the command, or global for all of the port adapters 
in the storage subsystem. In the local case, an entry for the 
volume group name would be created only in the volume 
access table stored in the port adapter that received the 
mount command. In the global case, an entry would be 
created for the group name in the volume access table in 
each port adapter of the storage subsystem. In any case, it 
would be desirable for a host to or host controller have the 
ability to access the volumes assigned to it through more 
than two of the ports in order to provide load balancing. This 
would include not only resending a data access request to 
another storage subsystem adapter port in response to a port 
adapter busy signal, but also spreading the host's load over 
a multipUcity or all of the storage subsystem adapter ports, 
for example in a round-robin fashion, to decrease the like- 
Uhood of any adapter port becoming busy. Such a method 
can be employed by a host to provide load balancing without 
any knowledge of the actual loading conditions on any of the 
ports, and without any coordination with the storage sub- 
system or other hosts. The round robin techruque can be 
implemented simply by the host or host controller incre- 
menting an index prior to sending each data access request, 
testing whether the index is equal to the number of sub- 
system adapter ports accessible to the host and if so resetting 
the index, and then directing the host's data access request 
to the accessible storage subsystem adapter port specified by 
the index. 

The gatekeeper facility responds to the unmount com- 
mand by checking whether the specified LUNs are all the 
LUNs assigned to the volume group name in the volume 
access table, and if so, removing the volume group name, 
and deallocating the volumes allocated to the group name. 
Normally, private volumes are erased when they are deal- 
located. There also could be an option to deallocate some but 
not all of the logical volumes assigned to a volume group 
name, and in this case only the entry for the volume group 
name would remain, but the volume Ust or LUN to logical 
volume map for the entry would change. 

When a controller is replaced, the "loss of fight" condition 
(when the controller is taken off line) will cause the auto- 
matic logout of the port firom the switch. (If a fabric exists, 
the problem of propagating the information through a fabric 
switch has not yet been solved by the FC standard.) This 
information will be passed on to the storage subsystem, 
which will remove the entry from the table. After the host is 
rebooted, the mount command wiU be executed and the 
connection will be re-established. 

Some hosts such as servers should be continuously logged 
in to the storage subsystem in the absence of a failure 
condition or planned removal from the data processing 
system. In this case, the host should unmount all of their 
assigned volumes before logging out for a planned removal. 
To respond to a failure condition, the storage subsystem 
could be programmed to respond to a report of a state change 
indicating that such a host has been discoimected from the 
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data network by checking the volume access table or tables 
for any volume group names corresponding to the host, and 
if any such volume group name has been found, reporting 
the error to the system administrator. The system adminis- 
trator can then decide whether any volumes allocated to the 5 
host should be deallocated and erased for use by other hosts. 

An example of a procedure using the host and storage 
subsystem facilities during a first-time host installation in 
the data network is as follows: 

1. The host controller of the host powers up. It performs lO 
its own initialization but does not execute any opera- 
tions related to volume configuration. 

2. The host boots over a host CD-ROM drive or local disk 
(for example in the case of a Fibre Channel storage 
network added to an existing system) or network stor- 
age such as a logical volume in the storage subsystem. 

3. Mountiiai network disk containing the host facilities 
(seen by the host as an application program) or load the 
host facilities from the host CD-ROM drive. 

20 

4. Start a graphical user interface for the host facilities and 
enter an Installation Mode. 

5. The host installation facility of the graphical user 
interface queries each host controller port for its port 
WWN. 25 

6. The host installation facility interrogates the data 
network for the WWNs of the storage subsystem ports. 
If the host controller port is in a Fibre Channel loop, 
then host installation faciKty probes the loop through a 
host controller for the WWNs . . . Otherwise, the host 3Q 
installation facility calls the fabric name server to 
obtain a hst of hst of SCSI device WWNs, and the full 
hst is searched for WWNs storage subsystem ports. 

7. The host installation facility reads the storage sub- 
system port text names, for example from block zero of 35 
the port configuration data in each storage subsystem's 
"gatekeeper" volimie at LUNO. If the port text name 
entries are zero, indicating that they have never, been 
entered by the system administrator, then a default of 
<storag6_sybsytem_name>/<storage_subsyst6m_ 40 
adapter_port #> is used. 

8. The host installation facility displays to the host user 
each storage subsystem adapter port WWN with its 
corresponding text name. 

9. When the host user selects a given storage subsystem 45 
adapter port WWN, the host installation facility 
executes a "Report LUNs" command. Using an appli- 
cation interface (API) function called getallprtlun(), aU 
of the LUN bitmap entries and their corresponding 
volume group names are read from the storage sub- 50 
system volume configuration database in the storage 
subsystem's "gatekeeper** volume at LUNO. The logi- 
cal OR of all of the bitmasks from each entry provide 

a single bitmask of all allocated volumes. While read- 
ing each entry, the host installation facility also checks 55 
each hostname as it appears in each volume group 
name returned from the API. This is compared with the 
current hostname in order to look for previous entries 
in the configuration database for this host. Upon 
completion of this sequence of actions, the host instal- 60 
lation facihty holds the following information: 
All volumes available on the storage subsystem adapter 
port; 

AU volumes on the storage subsystem adapter port that 
are already allocated to other hosts; 65 

All volumes that are already allocated to this host for this 
storage subsystem port; 
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Port WWNs for each host controller port of this host; and 

Port WWNs and text names for all storage subsystem 
ports available. 

10. The host user can create one set of allocated volumes 
for each host controller port residing on the host. The 
host facility graphical user interface associates an index 
number with each volume set, and displays to the host 
user each index number alongside each host controller 
port WWN. The graphical user interface also displays 
the volumes allocated to the host and those volumes 
that are not allocated to any host. The graphical user 
interface also displays, on demand, a list of volumes 
that are allocated to other hosts. From these, the user 
can select volumes to be allocated to the a selected host 
controller port of the host. If the volume is already 
allocated to another host and is marked as unshareable, 
an error is generated. 

11 If the host user initiates a save operation, the host 
installation facility writes all the configuration infor- 
mation along with the host controller port WWN to the 
storage subsystem voliime configuration database 
through the gatekeeper. The storage subsystem makes 
corresponding revisions to the volume access tables in 
its cache memory and port adapter memory. 

HOST AUTHENTICAnON 

In a storage system network, is desirable to authenticate 
host identity to prevent tampering with especially critical 
data such as the configuration information, which could 
enable imauthorized access to the most sensitive volumes of 
storage in the system. Therefore, whenever a host requests 
a change in the configuration information (i.e., write access), 
it is desirable to use a challenge -response protocol by which 
the host must identify itself in response to a request from the 
storage subsystem. Preferably this challenge-response pro- 
tocol incorporates a machine-based security feature that 
generates a response that cannot be re -used if intercepted. 

The machine-based security feature includes an encryp- 
tion key stored in memory of the hosts or host controllers. 
Each host controller, for example, has a unique encryption 
key that is different from the keys of the other host control- 
lers. Preferably the encryption key is stored in "write only*' 
memory of a monolithic semiconductor integrated circuit 
chip (hereinafter referred to as an "identity" chip) in such a 
way that the stored encryption key can only be read by 
encryption circuitry on the chip. The "write only" memory 
could be an electrically erasable and programmable read- 
only memory (EEPROM) array with a metal shielding layer 
over the memory array so that the stored key would be 
virtually impossible to recover by probing, inspection, 
disassembly, or "reverse engineering" of the identity chip. In 
this case, would be possible to publish the method by which 
the identity of the chip is authenticated. The identity chip, 
for example, is a microcontroller having such a write-only 
EEPROM program memory programmed to perform a 
unique encoding function corresponding to the key. The 
"write onl/* memory and the encryption circuitry could be 
a small portion of the circuitry on the identity chip. For 
example, the identity chip could be a microprocessor chip 
used as the main processor of a host controller circuit card 
or workstation. 

By incorporating the identity chip into the host controller, 
host motherboard, or the main processor chip of the host, is 
possible to verify the identity of the host controller, host 
motherboard, or main processor chip of the host. The 
identity chip, however, does not verify the identity of the 
user of the host. To guard against unauthorized users, it is 
still necessary to verify the identity of the user. ^t^J^ 
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verification would be done by the operatiog system in the 
usual fashion, for example at a user login time when the user 
is requested to enter a password. 

The identity chip could be attached to or incorporated into 
any kind of object or thing in order to authenticate the 
identity of that object or thing. For example, the chip could 
be embedded in a debit or credit card to authenticate the 
identity of the card before debiting or charging a corre- 
sponding account. The chip could be attached to an object or 
thing together with a wireless data transceiver to permit 
remote interrogation of the chip, for example in a tag 
implanted under the skin of an animal to remotely authen- 
ticate the identity of the animal. The identity chip could store 
descriptive information about the object or thing to which is 
attached, in order to permit verification that the identity chip 
has not been transferred to a different object or thing. If the 
descriptive information is unique to the particular object or 
thing, then the descriptive information could be incorporated 
into the secret key. For example, if the identity chip is used 
in a tag for an animal, part of the key could include a 
sequence of the genetic code of the animal. 

FIG. 29 shows a preferred construction for the identity 
chip. The identity chip 350 includes encryption circuitry 351 
and a "write-only" EEPROM memory 352 for storing at 
least one key 353. The key 353 can be written into the 
memory 352 from a data path 354 including external leads 
connected to the chip. The key 353 can be read from the 
memory 352 by the encryption circuitry, but the key cannot 
be read from the data path 354 or any other external leads 
connected to the chip. For example, the encryption circuitry 
352 includes a microprocessor 355 and a microcode read- 
only memory (ROM) 356 storing microcode executed by the 
microprocessor. The microprocessor is programmed to rec- 
ognize a command from the data path 354 for writing into 
the memory 352 a key from the buys 354. The micropro- 
cessor is also programmed to recognize a command from the 
data path 354 for receiving a number from the data path, 
reading the key 353 from the memory 352, encrypting the 
number with the key, and transmitting the encryption result 
onto the data path. The microprocessor, however, will not 
recognize any command for transmitting the key onto the 
datapath 354 or any other leads of the chip. In this sense, the 
memory 352 is a "write-only** memory. Moreover, the 
EEPROM memory 352 and at least the internal data path 
357 to the memory 352 are covered by an upper layer of 
metal 358 (shown in dashed lines in FIG. 31) on the chip 350 
so that it is virtually impossible for the key to be recovered 
by probing, inspection, disassembly, or "reverse engineer- 
ing** of the chip. The EEPROM 352 could store a plurality 
of different keys, and the microprocessor could recognize a 
command from the data path 354 for selecting which of the 
keys to use for encrypting the number received on the data 
path. 

FIG, 32 shows how identity chips 361, 363 are incorpo- 
rated in the data processing system of FIG. 1 for authenti- 
cating host controller identity. In this example, the Fibre 
Channel loop 41 is used for access to highly sensitive data, 
such as configuration information, stored in the cached 
storage subsystem 20. The identity chip 361 in the host 
controller 61 stores a unique secret key 362 for the host 
controller 61, and the identity chip 363 in the host controller 
62 stores a unique secret key 364 for the host controller 62. 
Copies of the keys 362, 364 are stored in a list 365 in the host 
controller. The list 365, for example, is a table, and each key 
in the list 365 is associated with the WWN of a respective 
host controller known to the port adapter. A copy of the list 
365 of keys is stored in a logical storage volume of the 
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storage subsystem, or the list of keys is stored in a nonvola- 
tile portion of the port adapter memory 77, so that the list 
will be retained if power to the port adapter is lost. Such a 
nonvolatile portion of the port adapter memory 77 could be 

5 provided by one or more identity chips constmcted as shown 
in FIG. 29. The port adapter memory 77 further includes a 
Ust 366 of random numbers sent to the hosts. The list 366, 
for example, is maintained as a queue. The list of random 
numbers 366 and the list of keys 365 are used by host 

10 authentication routines 367 in the port adapter microcode 
79. As the random numbers arc received by the hosts, the 
host controllers place the random numbers in similar hsts 
368, 269 in their respective memories 370, 371. As used in 
this specification, the term "random number" would include 

15 a so-called "pseudo -random number" so long as the number 
would appear to be selected at random during the tj^ical 
dvuration of time that a host controller is logged in to a port 
adapter. For example, the random numbers transmitted by 
the port adapter to a host controller are generated by a 

20 conventional random number generator routine that is 
seeded at the time that the host controller logs in to the port 
adapter. The BASIC programming language, for example, 
provides such a random number generator routine. 

Shown in FIG. 33 is a flowchart of the challenge-response 

25 protocol. The actions of the port adapter are shown on the 
left side of the flowchart, and related actions of a host 
controller are shown on the right side of the flowchart. The 
steps of the left side of the flowchart, for example, are 
performed by one of the host authentication routines (367 in 

30 FIG. 32). The challenge-response protocol is used, for 
example, when a host controller logs in to the port adapter. 
Prior to login, however, the system administrator must load 
the host controfler keys into the port adapter and host 
controllers. This should be done in a secure fashion, to 

35 guarantee that the keys caniiot be intercepted when they are 
distributed to the host controllers. The system administrator 
could load the keys into the port adapters through the service 
processor when assigning the logical storage volumes to the 
host controUers. In a similar fashion, the keys could be 

40 entered into each host controllers through a dedicated I/O 
port to avoid any need to transmit the keys over the data 
network. 

In a first step 381, the host controller sends a request to the 
port adapter for some work. In step 382, the port adapter 

45 receives the work request. In step 383, the port adapter 
responds to the work request by sending back a "challenge** 
request including a random number that is used as a one- 
time password. Since the number is random and changes 
every time it is needed, there is no way to predict it, nor 

50 record it and provide a false reply to a request for authen- 
tication. 

In step 384, the host controller receives the random 
number and the request for verification from the port 
adapter. In step 385, the port adapter encrypts the random 
55 number with its copy of the host controller's key. 
Concurrently, in step 386, the host controller encrypts the 
random number with its copy of the encryption key. The 
encryption process can use any kind of encryption technique 
smce the result never has to be decrypted. For example, the 
60 encryption could use the well-known method of the Data 
Encryption Standard (DES), or any sequence of encryption 
operations, for example, substitution, blocking, permutation, 
expansion, and compaction. It is also possible to use the 
well-known RSA public/private key system. In the conven- 
es tional use of the RSA system, public keys are used for 
encryption, and a private keys are used for decryption. 
Therefore, if the port adapter and the host controller used 
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RS A system, the public keys would be kept secret and would 
used for encoding, and the private keys would not be used. 

In step 387, the host controller sends the encryption value 
to the port adapter. In step 388, the port adapter receives the 
encryption value from the port adapter. In step 389, the port 
adapter compares the encryption value that it computed with 
the encryption value received from the host controller. If 
they match, then the host controller is authenticated, and the 
host controller is granted access to the storage subsystem. If 
they do not match, the host controller is denied access to the 
storage subsystem. 

One preferred way of applying the "challenge-response" 
protocol in a Fibre Channel network is by using the 
Exchange IDs (Originator and Responder) within the Fibre 
Channel header of the Frame Structure. The primary func- 
tion of the Fibre Channel network is to receive Frames from 
a source port and route them to a destination port. As shown 
in FIG. 30, a Frame 400 includes information to be trans- 
mitted (Payload 401), the source address (S_JD 402), the 
destination address (D_JD 403), and various kinds of link 
control information. 

Each Frame begins with a Frame Delimiter 404 indicating 
the start of the Frame. The Frame Delimiter 404 is imme- 
diately followed by a Frame Header 405. The Frame Header 
is used to control link applications, control device protocol 
transfers, and detect missing or out of order Frames. The 
Frame Header includes the source address (S_JD 402) and 
the destination address (D_ID 403). An optional header 406 
may contain additional link control information. The Pay- 
load 401 follows the Frame Header or the optional header. 
Four bytes of Cyclic Redundancy Check (CRC) follows the 
Payload. The CRC is used to detect transmission errors. The 
Frame 400 concludes with an End of Frame delimiter 408. 

The Exchange_ID 409 is an end portion of the Frame 
Header 405. The Exchange_ID includes an Originator_ID 
410 and a Responder_ID 411. The originator of a commu- 
nication sends the first message with a value specified as the 
Originator_JD. The Originator_ID must be unique amongst 
all the currently active exchanges. The responder receives 
the header. When it sends back a message, it places the 
Originator _JD plus its own Responder_JD into the header. 
This ID pair now comprises a unique Exchange_ID. 

Once a host controller has logged in to a port adapter, it 
is desirable to authenticate the host controller for each 
storage access request. If the challenge-response protocol of 
FIG. 33 were used for each storage access request, however, 
the traffic on the data network would be substantially 
increased because the Frame for each storage access request 
from the host controller would be followed by a Frame for 
the "challenge" message from the port adapter, and a Frame 
for the "response" of the host controller. In order to elimi- 
nate the "challenge" and "response" Frames, the port adapter 
and host controllers maintain and use the lists 366, 368, and 
369 of random numbers so that a host controller can include 
an encrypted value in the Exchange _JD of each storage 
access request. 

Referring to FIGS. 35 and 36, there is shown a flow chart 
of a preferred procedure for maintaining and using the lists 
366, 368, and 369 of the random numbers. In a first step 421 
of FIG, 35, a host controller sends a login request to a port 
adapter. In step 422, the port adapter receives the login 
request from the host controller. In step 423, the port adapter 
authenticates the host, for example by using the "challenge- 
response" protocol of FIG. 33. Then in step 434, the port 
adapter sends an initial set of random numbers to the host 
controller. The port adapter places these random numbers in 
its list 377. The list 377 is maintained as a set of first-in, 
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first-out (FIFO) queues including a respective queue allo- 
cated for the random numbers sent to each host controller. In 
a similar fashion, the host controller places the initial set of 
random numbers it receives in to its list 368 or 369 of 

5 random numbers. The host controller maintains its list as a 
set of FIFO queues including a respective queue for each 
port adapter that it has logged in to. The size of each FIFO 
queue, for example, is equal to the size of a queue that holds 
outstanding requests from the adapter ports or host control- 
ler ports. This is done so that the port adapter and host 
controller can encrypt the random numbers in their respec- 
tive queues as a background task relative to the outstanding 
requests. The host controller should typically produce the 
encryption value by the time that the host controller receives 
a request from the host to transmit a corresponding storage 

15 access request to the port adapter, and the port adapter 
should typically produce an encryption value by the time 
that the port adapter receives the corresponding encryption 
value in a storage access request ficom the host controller. 
The port adapter begins encryption in step 426, and the host 

20 controller begins encryption in step 427. 

Every time the host needs to send an authenticated storage 
access request to the storage subsystem, as shown in step 
428, the host controller takes the encrypted value of the next 
one of the random numbers in the FIFO queue for the port 

25 adapter, and uses the encrypted value as the Originator_JD 
in the Frame for the storage access request. In step 429, the 
port adapter receives the Frame from the host controller. In 
step 430, the port adapter compares the encrypted value in 
the Frame with its encryption of the next random number in 

30 its FIFO queue for that particular host controller. If there is 
no match, then the storage subsystem rejects the message. 
This is an error condition that is reported back to the host 
controller. If there is a match, then the requested storage 
access can proceed, as shown in FIG. 36. In step 431, the 

35 port adapter removes the last random number fi^om the FIFO 
queue for the host controller, and generates a new random 
number used as the Responder_ID in its reply to the data 
access request from the host controller, and places this new 
random number at the end of its list, in its FIFO queue for 

40 the host controller. In step 432, the host controller receives 
the response from the port adapter, and places the new 
random number at the end of its list, in its FIFO queue for 
the port adapter. In step 433, the port adapter continues 
encrypting the random numbers in its list, in the order in 

45 which the random numbers were put into the list. 
Concurrently, the host controller continues encrypting the 
random numbers in its list. In this fashion, the host controller 
will have in advance a random number to use as the 
Originator_ID in a next message, and depending on the 

50 priority of any other tasks, the host controller can encrypt the 
random number well before the encryption need be inserted 
into the next message. This ensures that the authentication 
method will not significantiy impart the storage access time 
in the data processing system. 

55 STORAGE NETWORK CONHGURAHONS 

FIG. 2 introduced a storage system configuration in which 
a respective Fibre Channel loop 41, 42, 43, 44 was liked to 
a storage subsystem adapter port, and a number of hosts 22, 
23, 24, 25 were linked to each loop, and each host was linked 

60 through a respective controller port to two loops. Such a 
fault -to ler ant network configuration should support from 
two (4K I/O) to ten (32K I/O) smaU server hosts per storage 
subsystem adapter port. The storage subsystem 20, for 
example, can be fiiUy loaded with sixteen adapter ports, 

65 which should support from 32 to 160 small server hosts. 
In contrast to small server hosts, workstation hosts have 
a relatively light loading on the storage subsystem adapter 
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ports. Also, fault tolerant links usually are needed between 
the workstations and the storage subsystem adapter ports. 
Therefore, as shown in FIG. 37, it is possible to link a large 
number of workstations 501, 502, 503, 504 to a cached 
storage subsystem 505 through a respective loop 506, 507 5 
linked to each adapter port. For example, in the storage 
network configuration of FIG. 37, each of sixteen loops 
could be linked to about fifty workstations, to network a total 
of about eight-himdred workstations to one storage sub- 
system. 10 

In a file-only environment (i.e., no video service), a single 
storage subsystem is capable of supportiag considerably 
more than eight-hundred workstations. If it is desired to 
network more than eight-hundred workstations to one stor- 
age subsystem, then a maximum of about fifty workstations 15 
per loop becomes a constraint. The number of workstations 
can be increased while meeting this constraint by using 
switches to increase the number of loops over the number of 
adapter ports. As shown in FIG. 38, for example, three 
sixteen-port switches 511, 512, 513 expand the number of 20 
ports coonectable to loops from the sixteen of the cached 
storage subsystem 514 to fifty-five. Each of the three sixteen 
port switches 511, 512, 513 has three of its ports connected 
directly to three respective storage subsystem adapter ports, 
and thirteen of its ports connected directly to loops, such as 25 
the loops 515, 516, 517 shown directly connected to a port 
of a respective one of the switches 511, 512, 513, This would 
permit the fifty-five loops to support a total of thirty-three 
hundred workstations, although the loops would not have 
similar performance since thirty-nine of the loops would be 30 
Unked directly to ports of the switches 511, 512, 513, and 
seven of the loops would be finked directly to storage 
subsystem adapter ports. 

Another environment where multiple hosts are connected 
to a storage subsystem is known as the cluster of storage area 35 
networks (SAN) environment. In this case, multiple hosts 
are linked to more than one storage subsystem, and the 
storage subsystems are Unked directly for the transfer of 
remote dual-copy data. This typically is not a high perfor- 
mance environment, but fault tolerance is a requirement. 40 
Therefore, there is a need for more than one path from each 
host to each storage subsystem. Shown in FIG. 39, for 
example, is a two-loop storage network configuration 
including a first cached storage subsystem 531, a second 
cached storage subsystem 532. The two cached storage 45 
subsystems are coupled by a direct link 533 for transfer of 
remote dual -copy data. The network configuration includes 
sixteen hosts, only the first host 534 and the sixteenth host 
535 being shown. A first loop 536 has links to one port on 
each of the cached storage subsystems 531, 532 and links to 50 
one port on each of the sixteen hosts 534, 535. A second loop 
537 also has finks to another port on each of the cached 
storage subsystems 531, 532 and to another port on each of 
the sixteen hosts 534, 535. 

If the network configuration of FIG. 39 would not provide 55 
sufficient throughput performance, then additional loops are 
added, and the number of hosts directly finked to each loop 
is decreased. Shown in FIG. 40, for example, is a four-loop 
configuration, including as before two cached storage sub- 
systems 541, 542 having a direct link 543 between them, and 60 
sixteen hosts, only the first host 544, the eighth host 545, the 
ninth host 546, and the sixteenth host 547 being shown. Two 
loops 548, 549 each have one direct link to one respective 
port on each of the cached storage subsystems 542, 543, and 
each of the fifst eight of the sixteen hosts, including, as 65 
shown, the first host 544 and the eighth host 545. None of 
the last eight of the sixteen hosts, including, as shown, the 



ninth host 546 and the sixteenth host, 547, have a port 
directly finked to the two loops 548, 549. Two loops 550, 
551 each have one direct fink to one respective port on each 
of the cached storage subsystems 542, 543 and each of the 
last eight of the sixteen hosts, including, as shown, hosts 9 
to 16. None of the first eight of the sixteen hosts, including, 
as shown, the first host 544 and the eighth host 545 have a 
port directly linked to the loops 550, 551. 
CONCLUSIONS 

From the above, it is seen that a number of facifities have 
described to provide various features and advantages in a 
data processing system having a large number of hosts 
networked to one or more cached storage subsystems, some 
or aU of which could be desired or required by any particular 
system users and managers. It should be apparent to a person 
of ordinary skill in the data processing art that the embodi- 
ments described above can be constructed to meet some or 
aU of the fofiowing requirements: 

A. General Requirements 

1. Any number of storage subsystems should be simply 
plugged into the network and easily configured by a 
system administrator for host access to selected vol- 
umes. 

2. Each entity in the data processing system (storage 
subsystem, data network, and host) should have sepa- 
rate and distinct management interfaces. The system 
administrator graphical user mterface, or host graphical 

y xiser interface, may provide a point of integration for 
the management interfaces of the entities. 

B, Data Network Requirements 

1. No path management internal to the data networic 
should be required. Path analysis is undesirable for 
providing connectivity to a host while retaining 
required performance, in a system having a very large 
number of hosts, and current network technology such 
as Fibre Channel fabric switches having at most a few 
tens of ports. The intemal structure of the data network 
can be complex, and in this case it is relatively difficult 
to analyze each path inside the data network, firom the 
host to the storage subsystem, to determine the correct 
port and path for each host. Since the number of hosts 
is very large, it is also an almost impossible task to 
directly control the performance requirements for a 
single host. With a large number of hosts, the perfor- 
mance typically will not cluster, but wiU have random 
hot spots constantly changing over time. 

2. Invisible internal path redundancy. There should 
always be at least two fuU redundant paths to reach the 
storage subsystem volumes from an extemal port of the 
data network. 

3. The ports and protocol to/from the storage subsystem 
and data network should comply with current 
standards, including both fabric and loop. Given the 
cost of a switch port and the number of hosts involved, 
it is expected that the fabric will be made up of a 
combination of loops and fabric direct connect. Each 
port going to/from the storage subsystem should simul- 
taneously support the different types of protocols. The 
external port type should be determined by the ^edfic 
solution. 

4. The storage subsystem should be allowed to register for 
notification of login state changes. The storage sub- 
system should keep cunent state information about the 
hosts and connections, especiaUy to allow single use of 
a group of volumes. One limitation of the Fibre Chan- 
nel protocol is that it does not support a logout. Along 
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with that is the issue of detecting the loss of a host (this the data network, wherein the storage controller is 

functionality is currently being developed in the FC programmed to provide a pluraUty of virtual ports that 

standard). are not physical ports in the data network but that 

5. On-line «hor management of data network coofigura- f^^^' ]^ processors to be physical ports in the 

5 data network that provide access to the data storage and 
that are connected to the physical data port by a switch 

6. Replacement of a host controller or storage subsystem ^ the storage controller for routing storage access 
director should not require any manual host-to-volume requests from the physical data port to the virtual ports; 
reconfiguration of the data network: wherein the storage controUer is programmed with a 

7. The switches used in the data network should be permanent network name for each of the virtual ports, 
interoperable with multiple fabric vendors. is programmed with a temporary network address for 

Storage Subsystem Requirements each of the virtual ports, and is programmed to route 

1. It is desirable to the storage subsystem to permit aU ^he physical data port to a specified virtual port a 
volumes to be seen through a single storage subsystem ^^-^^^S^ atxess request contaming a temporary address 
port. This eUminates the difficult management problem ^5 that specifies the speafied virtual port; 

of configuring and mamtaining the storage subsystem wherem the storage controller is programmed to provide 

and the data network to guarantee a path from a given ^^^^^f /f"^ ^ °^ ^ rcspecUve assigned 

external port of the data network to a given volume. ^""^^^^ f ^^^^ ^^""'^^^j . .... 

^ . , f . , , ...» , .„ wherem the storage controller is programmed to permit 

2. It IS desirable to have a partiUoning feature that will assignment of more than one virtual port to each host 
define the set of volumes that can be seen by a single 20 processor such that said each host processor may access 
host. This will restrict other hosts from seeing volumes storage from every virtual port assigned to said each 
they are not configured to see. host processor; and 

3. A change of a port ID (source id or worldwide name) wherein the storage controller is programmed so that none 
in the host should not affect the partitioning definition of the virtual ports is assigned to more than one host 
in requirement 2 above. 25 processor so that not more than one host processor may 

4. It is desirable to have a mapping feature that will allow ^^^^^s the data storage from any one of the virtual 
the host to specify its own LUN, which would be , ?!?/^' , , , • , • , - ^ 
mapped to a logical LUN within the storage subsystem. 2. The data storage subsystem as clamied m cbum 1, 

^ e> J wherem the storage controller is programmed to estabush a 

5. It is desirable to have the capability of selecting respective mapping at said each virtual port between logical 
between "simultaneous multi host access" to a volume, numbers addressable by one respective host processor 
and a "single host access" at a time. This is to control ^ ^hich said each virtual port is assigned, and correspond- 
data sharing capabilities. jjjg storage volumes of the data storage which said one 

6. It is desirable to limit host-to-volume access to read- respective host processor may access from said each virtual 
only or read/write. 35 port. 

7. Each port should simultaneously support all SCSI 3. The data storage subsystem as claimed in claim 1, 
address modes. wherein at least a first virtual port and a second virtual port 

8. Each port should simultaneously support both Fibre ^re assigned to at least one host processor such that said at 
Channel class 2 and class 3. 1^^^' ^^^^ processor can access from the first virtual port 

„ „ , , ^ , • T-n. 1. 1 • u ij 40 only private Storage that is not shared with any Other host 

9. Both loop and fabnc Fibre Channel topologies should ^ j • j * 1 * i_ . 

^ ^ & processor, and said at least one host processor can access 

' from the second virtual port storage that is shared with 

10. It should be possible to back up and restore the another host processor. 

host-to-volume connectivity configuration information. 4 xhe data storage subsystem as claimed in claim 1, 

11. The storage subsystem should allow a volume to be 45 wherein the storage controller is programmed to provide a 
used as boot disk for a host. name server for responding to a name server request from 

12. Replacement of a host controller or storage subsystem the network by identifying the virtual ports and providing 
director should not require any manual host-to-volume network addresses of the virtual ports, and the storage 
reconfiguration of the storage subsystem. controller is farther programmed to provide a facility for 

I. Host Requirements 50 reporting to a host processor the virtual ports from which the 

1. The host should be responsible for establishing a host processor may access the data storage, and the subset of 
connection with the storage subsystem. ^^^^ storage that the host processor may access from 

u . u ij u *t_ * • .u each of the virtual ports from which the host processor may 

2. The host should have the capabihty of specifymg the ^^^^^ ^^^^^ ^ ^ 

target LUN information to be used in mapping LUNs to c-ruj*. u* i-j i-i 
, ^ . , I'i' & 55 5. rhe data storage subsystem as claimed m claim 1, 
logical storage volumes. wherein the storage controUer is programmed so that the 
3- The host should provide security for the configuration ^^^^^^^ p^^s and the switch are substantially compliant with 
information (volume group and LUNs) that it uses to Fibre-Channel network standards applicable to Fibre- 
establish connectivity with the storage subsystem. Channel physical ports and Fibre-Channel fabric. 
What is claimed is: 60 6. A machine-readable program storage device that is 
1. A data storage subsystem comprismg, m combmation: executable by a storage controUer for controlUng access to 
data storage; and data storage, said storage controller having at least one 
a storage controUer coupled to the data storage for con- physical data port for connecting the storage controller into 
trolling access to the data storage, the storage controller a data network for data transmission between the data 
having at least one physical data port for connecting the 65 storage and host processors in the data network, 
storage controller into a data network for data trans- wherein the program is executable by the storage con- 
mission between the data storage and host processors in troller to provide a plurality of virtual ports that are not 
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physical ports in the data network but that appear to the 
host processors to be physical ports in the data network 
that provide access to the data storage and that are 
connected to the physical data port by a switch in the 
storage controller for routing storage access requests 5 
from the physical data port to the virtual ports; 

wherein the program is executable by the storage con- 
troller so that the storage controller will have a perma- 
nent network name for each of the virtual ports and a 
temporary network address for each of the virtual ports, 
and the program is executable by the storage controller 
to route from the physical data port to a specified virtual 
port a storage access request containing a temporary 
address that specifies the specified virtual port; 

wherein the program is executable by the storage con- "^^ 
troller to provide access at each virtual port to only a 
respective assigned subset of the data storage; 

wherein the program is executable by the storage con- 
troller to permit assignment of more than one virtual ^ 
port to each host processor such that said each host 
processor may access storage from every virtual port 
assigned to said each host processor; and 

wherein the program is executable by the storage con- 
troller so that none of the virtual ports is assigned to 25 
more than one host processor so that not more than one 
host processor may access the data storage from any 
one of the virtual ports. 

7. The machine-readable program storage device as 
claimed in claim 6, wherein the program is executable by the 30 
storage controller to establish a respective mapping at said 
each virtual port between logical unit numbers addressable 
by one respective host processor to which said each virtual 
port is assigned, and corresponding storage volumes of the 
data storage which said one respective host processor may 35 
access from said each virtual port. 

8. The machine-readable program storage device as 
claimed in claim 6, wherein the program is executable by the 
storage controller to assign at least a first virtual port and a 
second virtual port to at least one host processor such that 40 
said at least one host processor can access from the first 
virtual port only private storage that is not shared with any 
other host processor, and said at least one host processor can 
access from the second virtual port storage that is shared 
with another host processor. 45 

9. The machine -readable program storage device as 
claimed in claim 6, wherein the program is executable by the 
storage controller to provide a name server for responding to 
a name server request from the network by identifying the 
virtual ports and providing network addresses of the virtual 50 
ports, and the program is executable by the storage control- 
ler to provide a facility for reporting to a host processor the 
virtual ports from which the host processor may access the 
data storage, and the subset of the data storage that the host 
processor may access from each of the virtual ports from 55 
which the host processor may access the data storage. 

10. The machine-readable program storage device as 
claimed in claim 6, wherein the program is executable by the 
storage controller so that the virtual ports and the switch are 
substantially compliant with Fibre-Channel network stan- go 
dards applicable to Fibre-Channel physical ports and Fibre- 
Channel fabric. 

11. A method of operating a storage controller for con- 
trolling access to data storage, the storage controller having 
at least one physical data port for connecting the storage 
controller into a data network for data transmission between 
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the data storage and host processors in the data network, said 
method comprising: 

the storage controller receiving storage access requests 
from the host processors at the physical data port, and 
inspecting network addresses in the storage access 
requests to find network addresses of virtual ports in the 
storage controller to which the storage access requests 
are directed, and controlhng access to the data storage 
in accordance with the network addresses of the virtual 
ports to which the storage access requests are directed, 
wherein the virtual ports are not physical data ports in 
the data network, but the storage controller is operated 
to cause the virtual ports to appear to the host proces- 
sors to be physical ports in the data network that 
provide access to the data storage and that are con- 
nected to the physical data port by a switch in the 
storage controller for routing storage access requests 
from the physical data port to the virtual ports; 

wherein the storage controller maintains a permanent 
network name for each of the virtual ports and a 
temporary network address for each of the virtual ports; 

wherein the storage controller provides access at each 
virtual port to only a respective assigned subset of the 
data storage; 

wherein the storage controller permits assignment of more 
than one virtual port to each host processor such that 
said each host processor may access storage from every 
virtual port assigned to said each host processor; and 

wherein none of the virtual ports is assigned to more than 
one host processor so that not more than one host 
processor may access the data storage from any one of 
the virtual ports. 

12. The method as claimed in claim 11, wherein the 
storage controller maintains a respective mapping at said 
each virtual port between logical unit numbers addressable 
by one respective host processor to which said each virtual 
port is assigned, and corresponding storage volumes of the 
data storage which said one respective host processor may 
access from said each virtual port. 

13. The method as claimed in claim 11, wherein the 
storage controller assigns at least a first virtual port and a 
second virtual port to at least one host processor such that 
said at least one host processor can access from the first 
virtual port only private storage that is not shared with any 
other host processor, and said at least one host processor can 
access from the second virtual port storage that is shared 
with another host processor. 

14. The method as claimed in claim 11, wherein the 
storage controller responds to a name server request from 
the network by identifying the virtual ports and providing 
network addresses of the virtual ports, and the storage 
controller reports to a host processor the virtual ports from 
which the host processor may access storage, and the subset 
of the data storage that the host processor may access from 
each of the virtual ports from which the host processor may 
access the data storage. 

15. The method as claimed in claim 11, wherein the 
storage controller transmits data to and receives data from 
the network so that the virtual ports and the switch are 
substantially compliant with Fibre-Channel network stan- 
dards applicable to Fib re- Channel physical ports and Fibre- 
Channel fabric. 

« 4 * m * 
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